[jjohnstn: initial version of iconv support checked in]

[Nicholas Wourms]

wrote:

> 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

and...

B) impossible, by design, for ld to re-export symbols found in libc[1]

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 [1])

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.

Cheers,
Nicholas

[1] 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.