This is the mail archive of the
mailing list for the Cygwin project.
Re: Bug in libiconv?
On 1/27/2011 7:20 AM, Corinna Vinschen wrote:
> I got it working. The major reason was that the conversion to wchar_t
> was broken due to the #if expressions in lib/iconv.c and
> #if __STDC_ISO_10646__ || ((defined _WIN32 || defined __WIN32__) && !defined __CYGWIN__)
> This should be
> #if __STDC_ISO_10646__ || defined _WIN32 || defined __WIN32__
> #if __STDC_ISO_10646__ || defined _WIN32 || defined __WIN32__ || defined __CYGWIN__
> Other than that, here's the full patchset which I applied to let
> libiconv work more POSIXy on Cygwin. I tested especially that the Linux
> code works fine on Cygwin as well. Use the patch at you own leasure.
> If you have any questiosn, feel free to ask.
Thanks for the patch. I'll use the reloc bits as the basis for a patch
upstream to gnulib...but unless you:
1) configure libiconv with --enable-relocate and
2) then installed into /not/the/tmpdir
then you didn't actually test the relocation stuff.
Don't worry about it tho; I'll do that. (I also need to research why we
didn't use /proc/self/maps originally, since it was available in 1.5. I
don't think this historical data matters NOW, tho, since surely it's
been around long enough we can assume its presence... The downside for
me is that it was NOT around in 1.3.x -- which means my port of libiconv
for the-fork-that-shall-not-be-named will have to *undo* this patch
locally. Oh well.)
The important thing, in my mind, is getting the charset conv stuff
working correctly. That stuff makes my teeth itch, so I'm very grateful
you tracked it down!
One question: does it matter if the code is changed, in libiconv, as you
suggest, and then libiconv is built on old-cygwin:
1) 1.3.x (e.g. fork-that-shall-not-be-named)
or, for upstream submission, do I need to be careful about versions and
munge all of the #ifdefs appropriately?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple