Subject: Re: bin/12017: how to enable multibyte locale (and problem around it)
To: None <firstname.lastname@example.org (NetBSD GNATS submissions and>
From: None <email@example.com>
Date: 01/22/2001 10:17:09
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.