[OpenIndiana-discuss] [developer] Gnome and the future

[Alex Caudill]

On Sun, Nov 4, 2012 at 9:46 AM, James Carlson <carlsonj at workingcode.com> wrote:
> On 11/04/12 09:06, Irek Szczesniak wrote:
>> This is useless because you still do not have newlocale(), duplocale()
>> or uselocale() which create or use the locale_t object.
>
> Those can be dummied out as well.

For example:

http://git.musl-libc.org/cgit/musl/tree/src/locale/duplocale.c
http://git.musl-libc.org/cgit/musl/tree/src/locale/freelocale.c
http://git.musl-libc.org/cgit/musl/tree/src/locale/newlocale.c
http://git.musl-libc.org/cgit/musl/tree/src/locale/setlocale.c

I'm actually using this code nearly verbatim on OpenIndiana.

>
>> The point of the new apis is that you can have an unlimited number of
>> locale_t objects, all with different properties. As side effect
>> different threads can use different locale_t objects, giving threads
>> the ability to run in different locales. But this feature is NOT
>> limited to per-thread locales as some people may think.
>
> I think the underlying point that the previous poster was making was
> that for a significant number of users, the desktop environment is
> launched with the per-process locale set correctly, and the user happily
> spends all of his time in that single locale.  Being able to switch
> locales on a thread-by-thread basis is certainly nifty, and is perhaps
> useful in some service providing scenarios (e.g., a web server), but
> it's quite unclear at least to me how it'd be very much helpful to build
> a window manager.  Perhaps there are multi-lingual people who really do
> need to have a window manager that can decorate each window differently
> ... but really?

I just wanted to share an approach for Getting This Stuff To Work(TM).

As far as I'm aware, using these stubs is the only way to compile
libc++ and, by extension, a self-hosted clang 3.2 (with no
libstdc++/g++ dependency).

Beyond that, I don't have any opinion about xlocale.