[jjohnstn: initial version of iconv support checked in]
Thu Jan 29 11:09: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. 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.
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.
Just my $0.02 (canadian - which is where I will be going in two wheels and
three spokes )
1: OK: "wheel" was just a type-o, but I thought it was funny... Anyways,
"the month" will start Feb 17th and if finances permit might be
extended a bit..
On Wed, Jan 28, 2004 at 09:56:44PM +0100, Christopher Faylor wrote:
> The below is just an FYI.
> This means that the iconv stuff could be built into the DLL, bloating the dll
> even more I suppose.
> Is this something that we want to do? I vote no, but I thought I should mention
> this to the collective wisdom of cygwin-apps since it essentially boils down to
> a package issue.
> ----- Forwarded message from Jeff Johnston -----
> From: Jeff Johnston
> To: newlib
> Subject: initial version of iconv support checked in
> Date: Fri, 23 Jan 2004 16:56:09 -0500
> This is just to note that the initial version of Artem Bityuckiy's iconv
> code has been checked in. It can be activated using the configuration
> Builtin iconv converters can be selected using the configuration option:
> This iconv code cannot currently be used with i686-pc-linux-gnu which
> has its own iconv support.
> Thanks to Artem for this major piece of work.
> -- Jeff J.
> ----- End forwarded message -----
Pollyanna's Educational Constant:
The hyperactive child is never absent.
More information about the Cygwin-apps