This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [jjohnstn: initial version of iconv support checked in]


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


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]