Re: Fix libunistring in MS-Windows locales

Eli Zaretskii wrote in : > One reason is that libunistring needs to know the codeset of the > locale, to use it when it converts strings to and from Unicode using > iconv. However, on Windows the function locale_charset always re

Re: Fix libunistring in MS-Windows locales

> From: Daiki Ueno > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org > Date: Thu, 07 Aug 2014 09:22:32 +0900 > > Eli Zaretskii writes: > > >> > Actually, I see that libunistring already includes functions for > >> > locking (which on Windows wrap the 2 APIs I mentioned above). So I > >> > guess it

Re: Fix libunistring in MS-Windows locales

Eli Zaretskii writes: >> > Actually, I see that libunistring already includes functions for >> > locking (which on Windows wrap the 2 APIs I mentioned above). So I >> > guess it's best to use them. >> >> Yes, could you create a patch in that direction? > > Will do. Here is a simple patch for t

Re: Fix libunistring in MS-Windows locales

> From: Daiki Ueno > Cc: bug-gnulib@gnu.org, egg...@cs.ucla.edu > Date: Sat, 19 Jul 2014 08:11:11 +0900 > > Eli Zaretskii writes: > > > . __thread works as expected in MinGW GCC since version 4.5.0 > > > > . DLLs that use __thread (a.k.a. "implicit TLS") cannot be safely > > loaded at

Re: Fix libunistring in MS-Windows locales

Eli Zaretskii writes: > . __thread works as expected in MinGW GCC since version 4.5.0 > > . DLLs that use __thread (a.k.a. "implicit TLS") cannot be safely > loaded at run time, using LoadLibrary, on Windows versions before > Vista, they can only be loaded at program startup time (IOW

Re: Fix libunistring in MS-Windows locales

> Date: Fri, 18 Jul 2014 12:29:09 +0300 > From: Eli Zaretskii > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org > > Or maybe we should simply go back to your idea of locking, e.g., by > using EnterCriticalSection and LeaveCriticalSection? Actually, I see that libunistring already includes functions f

Re: Fix libunistring in MS-Windows locales

> From: Daiki Ueno > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org > Date: Fri, 18 Jul 2014 16:06:11 +0900 > > FWIW I just tried myself (on wine, though) and it seems to work with: > > - GCC 4.8.3 (Fedora mingw64-gcc package, cross compiling) > - GCC 4.7.2 (mingw-w32-bin_i686-mingw_20111219, self

Re: Fix libunistring in MS-Windows locales

Daiki Ueno writes: > I could be wrong and perhaps it might not be a problem with the recent > MinGW releases. FWIW I just tried myself (on wine, though) and it seems to work with: - GCC 4.8.3 (Fedora mingw64-gcc package, cross compiling) - GCC 4.7.2 (mingw-w32-bin_i686-mingw_20111219, self comp

Re: Fix libunistring in MS-Windows locales

Eli Zaretskii writes: >> I'm not familiar with Windows TLS support, but '__thread' seems to be >> compiler specific. > > Do we care for any Windows compilers except GCC? I was rather worried about particular versions of GCC, which might not support it at all (< 3.3?), or might require extra comp

Re: Fix libunistring in MS-Windows locales

Eli Zaretskii wrote: Do we care for any Windows compilers except GCC? Not as far as I know, for Gnulib. (Though I'm no Windows expert.)

Re: Fix libunistring in MS-Windows locales

> From: Daiki Ueno > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org > Date: Thu, 17 Jul 2014 12:59:59 +0900 > > Eli Zaretskii writes: > > >> By the way, isn't there a minor race in gl_locale_name_thread, since it > >> depends on a global variable found_lcid? > > > > Yes. (It is not a problem for

Re: Fix libunistring in MS-Windows locales

Eli Zaretskii writes: >> By the way, isn't there a minor race in gl_locale_name_thread, since it >> depends on a global variable found_lcid? > > Yes. (It is not a problem for Guile, since Guile built with threads > on Windows is severely broken, so the only way of having a useful > Guile on Wind

Re: Fix libunistring in MS-Windows locales

> From: Daiki Ueno > Cc: Paul Eggert , bug-gnulib@gnu.org > Date: Wed, 16 Jul 2014 19:02:03 +0900 > > Do you need a new libunistring release with this change? I think it would be good, yes. > I don't even know if Guile is still using the packaged libunistring. It does, at least as of its late

Re: Fix libunistring in MS-Windows locales

Eli Zaretskii writes: >> Date: Tue, 15 Jul 2014 12:20:44 -0700 >> From: Paul Eggert >> >> Thanks, I installed that, with minor changes to indentation and suchlike. > > Thank you. Sorry for not looking at it timely. Do you need a new libunistring release with this change? I don't even know if

Re: Fix libunistring in MS-Windows locales

> Date: Tue, 15 Jul 2014 12:20:44 -0700 > From: Paul Eggert > > Thanks, I installed that, with minor changes to indentation and suchlike. Thank you.

Re: Fix libunistring in MS-Windows locales

Thanks, I installed that, with minor changes to indentation and suchlike.

Re: Fix libunistring in MS-Windows locales

Ping! Almost 2 weeks went by with no response. TIA > Date: Thu, 03 Jul 2014 18:23:32 +0300 > From: Eli Zaretskii > > I submitted these changes to the libunistring mailing list, but was > advised to send them here, as libunistring appears to be a collection > of Gnulib modules. So here I am, r

Re: Fix libunistring in MS-Windows locales

Karl Berry wrote: However, what is the benefit to labelling individuals as maintainers of modules in the first place, rather than just having everything be "all"? Was it that Bruno wanted to personally approve changes to "his" modules? Yes, that was basically it. As I recall, Bruno was the one

Re: Fix libunistring in MS-Windows locales

You didn't volunteer for libiconv- and gettext-related modules so I reverted their maintainer to 'all'; Daiki has been the maintainer of gettext (the package) for quite some time, as you know. I asked him about libiconv (the package) in other email; I'm guessing he'll reply after the we

Re: Fix libunistring in MS-Windows locales

k...@freefriends.org (Karl Berry) writes: > Daiki, would you like to become the new maintainer? If nobody else is interested, I can take it. > Alternatively, if you think libunistring as a separate entity should > go away and it just be part of gnulib, that's fine. Ditto libiconv > (another of

Re: Fix libunistring in MS-Windows locales

As far as I know, bug-libunistring is still intended to exist independent of gnulib. At least I have never heard otherwise from Bruno. However, Bruno has just today officially stepped down as maintainer of libunistring, and all his other remaining packages. Daiki, would you like to become the ne

Fix libunistring in MS-Windows locales

I submitted these changes to the libunistring mailing list, but was advised to send them here, as libunistring appears to be a collection of Gnulib modules. So here I am, repeating what I sent to libunistring list. (The patch below is relative to the latest Gnulib master.) Libunistring on MS-Win