[jjohnstn: initial version of iconv support checked in]
Thu Jan 29 14:29:00 GMT 2004
> Please don't: we already have a perfectly good iconv implementation in the
> distribution and there's no law against providing iconv as a separate library
> from the kernel/libc/whatnot.
Of course it isn't "against" the law, but the fact is that most modern,
non-microsoft, libc's provide it. Not all apps are GNU and some require
a good deal of retooling to get them to recognize our libiconv. You
also might want to consider the interests of our current libiconv
maintainer, who also happens to maintain quite a few other core
packages. I'm almost certain that he'd welcome not having to prepare
and release new libiconv versions. Also, you forget the fact that some
of the binaries packaged in the Cygwin dll package rely on the external
libiconv. IMHO, applications which are part of that core package really
ought not to rely on a library external to those provided by
cygwin/w32api/newlib/libiberty. Finally, it might be something desired
by those looking to actually pay $$$ to license the Cygwin dll for use
in non-GPL projects.
> By far most applications don't care too much
> about transcoding, so most applications would simply have to carry around
> some extra luggage if it were built into the Cygwin DLL.
Stop spreading FUD, that last part isn't true at all. There is no
"extra baggage", if anything, application sizes might be reduced by a
minuscule amount. This is assuming one less external library would make
for a slightly smaller PE header. However, since it is:
A) impossible, by design, to statically link with Cygwin's libc
B) impossible, by design, for ld to re-export symbols found in libc
this concern really is a moot one.
> That, and I wonder how libiconv would interact with this.. but as I haven't
> given that any thought at all (only one neuron assigned to the task for the
> next two seconds or so) I wouldn't be willing to make any guesses about that.
Simple, this replaces libiconv. The libiconv dev package would be
obsoleted, replaced with an empty one, however we would retain current
libiconv runtime libs for compatibility. This won't affect applications
built against the old libiconv since the old libiconv data files aren't
clobbered by newlib's iconv. Shared & static libraries, however, would
need to be rebuilt since libiconv uses different symbols from the libc
iconv (it uses #define's in iconv.h to alias the expected symbols, such
as iconv_open, to the libiconv versions.
> Just my $0.02 (canadian - which is where I will be going in two wheels and
> three spokes )
Which is about $0.0125 US...
As I said before, I think we should take a "wait and see" approach.
There's no rush or reason to make a decision now, since it is disabled
by default. Let some people try it out on their own and report back
with their findings. We can always revisit this at a later time, once
the newlib iconv support is more mature.
 This, of course, is assuming the default case and does not consider
the operations done during the building of the Cygwin dll or those
involving custom ld scripts.
More information about the Cygwin-apps