it seems to me that there are a couple of twists in dlopen() handling
	in NetBSD.
	1. static linked binaries cannot use dlopen().
	2. if we use dlopen() from inside the library (like citrus locale
	   code was trying to do), ld.elf_so will become very broken.
	   in my case,
	   - ld.elf_so binary via calls to printf(),
	   - printf() calls locale related functions like mbrtowc(),
	   - mbrtowc() calls locale framework,
	   - i'm testing some code with dlopen() in locale framework.

	i'm not sure how this should be addressed.
	- is it okay to forbid statically linked binaries from using dlopen()?
	- how do we want to compile ld.elf_so?
	- assume that we have very large locale code in libc.  is it a good
	  idea to supply, for example, libnolocale.a, so that we can do:
	  % cc foo.c -lnolocale
	  to avoid locale handling code (and bring in simplified locale
	  handling code)?

itojun