On Thu, Jan 29, 2004 at 09:29:46AM -0500, Nicholas Wourms wrote: > rlc 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. I understand that not all software is GNU - I work on non-GNU software most of the time. As for the re-tooling of apps to recognise libiconv - most of those apps will probably need re-tooling for other iconv implementations as well. AFAIC, the mere fact that porting an application may need a wee bit of work for an iconv implementation (one which, currently, is not Cygwin-specific in any way) doesn't mean all that much to me: the same iconv implementation is available on many platforms and, as such, the effort of porting to Cygwin will simply help porting to those platforms as well..
> 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. I don't know that - haven't heard from him. What I also haven't heard is that including an iconv implementation in Cygwin would automatically mean no longer distributing GNU iconv, but that's another story. > 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. Ehm.. why? > Finally, it might be something desired by those looking to actually pay > $$$ to license the Cygwin dll for use in non-GPL projects. AFAIK (but correct me if I'm wrong) the commercially licensed Cygwin is not necessarilly the same as the Net release - in which case iconv could easily be built into that one. Otherwise, IIUC, the iconv implementation that could be built into Newlib can be built as a separate library, which would be available under the same licensing terms as Newlib itself (i.e. BSD-like license). That basically means there's an alternative to GNU iconv ported to Cygwin already.. >> 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. It is definitely not my intention to spread FUD, but you're probably right: an iconv implementation hardly qualifies as code bloat. >> 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. There's a point I definitely wouldn't be happy with: I like GNU's iconv and don't know Newlib's new iconv, so anything I wrote that uses iconv would need new QA. Personally, I would much prefer peaceful cohabitation of the two iconvs for as far as that is possible - and AFAIK, that should be possible because of the #defines in iconv. > >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. Yes: we can always revisit this later - I was just voicing my first concern about a new, possibly incompatible, iconv implementation. I have no intention to spread any FUD and I am confident that nothing important will be broken any time soon. I should probably have phrased my "please don't" as a "please wait" :) rlc -- In success there's a tendency to keep on doing what you were doing. -- Alan Kay