On Tue, Dec 26, 2000 at 07:32:34PM +0900, Jun-ichiro itojun Hagino wrote:
> 	it seems to me that there are a couple of twists in dlopen() handling
> 	in NetBSD.
> 	1. static linked binaries cannot use dlopen().

I think this is a mistake.

I've run into this problem on either HP-UX or Solaris (I don't remember
details). This is actually pretty irritating. What I wanted to do was
compile an Apache binary with mod_perl (and a few other modules, including
mod_ssl). The Apache binary was supposed to be static. The problem was
I wanted Perl to be able to dynamically link in modules while mod_perl
was supposed to be linked statically.

Also, I was linking in some AFS code for authentication and authorization.
Since on HP-UX this meant I had to link in the BSD library but first I
had to link in libc, but I wanted to link in libc static and then dynamic,
then I had to include this mess in my final link:
-static -lc -lBSD -lc -dynamic -lc 

If HP-UX had been able to compile a true static binary that could do
dynamic linking anyway then I could have simplified that gunk a bit. (I
don't remember what specialness Solaris had).

I really dislike systems that cannot do true static linking, but that's
a different point. 

I think that forcing static linked binaries to not be able to use dlopen()
would be a mistake and will be a burr in someone's butt sometime in the
future. Personally I find having to link dynamically to do run-time
dynamic linking is counterintuitive. Conceptually, what do these two
things have to do with each other? 

Does anyone actually think of linking a program dynamically so they can
use dlopen()? I didn't, and was irritated when I had to link dynamically.
-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/

"Nonbelievers found it difficult to defend their position in \ 
    the presense of a working computer." -- a DEC Jensen paper