[just a redirection to the 'tech-userlevel' list]

itojun-san wrote:
> 	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.
> 
> itojun

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
adopted.

Masao

---
Masao Uebayashi <uebayasi@soum.co.jp>