>: 	it was found that, with older crt0.o, it is impossible to use dlopen()
>: 	from within libc (unless the user application code uses dlopen already).
>: 	if we put reference to libc, older binaries dies with unresolvable
>: 	symbol.  i'll try to hack it up, or change some strategy.  anyway,
>: 	it won't appear too soon.  sorry about the noise.
>Static binaries plus dlopen() is a very tricky (and in some cases completely
>losing) proposition.  You need a dynamic linker (/usr/libexec/ld.{elf_,}so)
>to make that work.  It's best not to attempt to use dlopen() from static
>binaries.

	i understand issue with static binary, so i (or we?) already have
	chosen not to try supporting multibyte locale this time:
>: >	- libc.a (for static linked binary) can enjoy singlebyte locale only.

	the problem i had is with older shared binaries.
	with older shared binaries, dlopen() symbol is not in crt0.o.
	so there's no dlopen() available if user application do not reference
	it.  in this case, from within libc, we cannot reference dlopen().

	i experienced this behavior with my not-too-old tcsh (built Dec 1999).
	ld.elf_so jus tbombs with "dlopen is not resolvable".

	so i'm convinced that by doing below, i'll get burned alive
	with tons of trouble reports :-)
>: >	- libc.so (for shared binary) can enjoy multibyte locale library
>: >	  support.  multibyte locale support needs /usr/lib/runemodule/*.so to
>: >	  get dlopen'ed at runtime.

itojun