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