Subject: Re: bin/12017: how to enable multibyte locale (and problem around
To: None <firstname.lastname@example.org>
From: Masao Uebayashi <email@example.com>
Date: 01/22/2001 13:26:42
[just a redirection to the 'tech-userlevel' list]
> so try to summarize the current situation:
> - if you do not call setlocale() from within your program,
> your binary won't have multibyte locale stuff pulled in.
> - if you do call setlocale() from within your program,
> multibyte locale stuff will be pulled into your program.
> - now ld.elf_so issue (issue (b) in the original summary) is no longer
> there. it is okay (unless someone introduce a call to setlocale()
> in ld.elf_so source code).
> so, remaining issue is:
> (a) whether it is okay to call dlopen() from within libc
> if it is okay to use dlopen(), that's fine with me.
> it seems that there are objections to it. i can understand those
> objections, since this can be seen similar to PAM, and I find PAM a
> scary idea (BSDI BSD authentication code is much better).
> statically lined binaries cannot use multibyte locale however,
> due to dlopen() restriction.
> if it is not okay, that's fine with me too. we need to modify
> lib/libc/locale/setrunelocale.c and recompile libc when we see a
> new encoding defined, but given the expected frequency of such an
> event, that's okay with me. a good thing is that we can use
> multibyte locale from within statically-linked binary, independent
> from the lack of dloepn() support in statically-linked binary.
> in either way, i have working patches.
> i just want a consensus here.
As one longing-for-I18N user, I have no idea and any option is
okay. :) My only hope is that more sophisticated design will be
Masao Uebayashi <firstname.lastname@example.org>