Mail Archives: cygwin/2011/01/27/12:08:52
On Jan 27 11:21, Charles Wilson wrote:
> 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
> > lib/iconv_open1.h:
> >
> > #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
> --prefix=/some/really/wierd/tmpdir, AND
> 2) then installed into /not/the/tmpdir
> then you didn't actually test the relocation stuff.
What I did was to run my testapp under GDB and to check that the
find_shared_library_fullname() function as well as the calling function
get_charset_aliases() were doing as expected.
> 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
Well, there's a comment in the original code which refers to this.
See srclib/progreloc.c, line 149ff. The comment basically says that
the functionality is known, but we don't use them because it doesn't
match what we do elsewhere. The fact that the code elsewhere wasn't
required for Cygwin anymore was not noticed for some reason.
> don't think this historical data matters NOW, tho, since surely it's
> been around long enough we can assume its presence...
Yep.
> 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)
> 2) 1.5.x
> 3) 1.7.1--1.7.7
> or, for upstream submission, do I need to be careful about versions and
> munge all of the #ifdefs appropriately?
Cygwin Versions prior to 1.7.7 are not support anyway. The changes
should work with versions at least back to 1.7.2 and I don't care the
least for older versions. There's no reason to clutter the code to
support old, unsupported Cygwin versions. There are existing, older
builds of libiconv available for them.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -