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

[Ronald Landheer-Cieslak <blytkerchan at users dot sourceforge dot net>]

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