On Tue, 27 Aug 2002, Noriyuki Soda wrote:

> >>>>> On Mon, 26 Aug 2002 19:52:59 +0100, Ben Harris <bjh21@netbsd.org> said:
> 
> > As I understand it, the major problem is that there's no sensible way for 
> > the dlopen()ed object to get at symbols in the statically-linked program.   
> > This means it has to end up with its own version of any libraries that it's
> > linked against, and in particular with its own version of all their global
> > variables.  In the case of libc, this includes things like errno, the malloc
> > arena, stdout and so forth.
> 
> And even if there is a way to get such symbols. There is a still
> following problem:
> 	http://mail-index.netbsd.org/tech-userlevel/2001/12/22/0002.html

Hmmm. It might be a problem if the semantics or parameters of a function
would change, I can see that. You don't know which version of a library is
statically linked, so using that library for the dynamically linked
references is dangerous. But at the same time, some global variables
*have* to be shared. The conflict cannot be solved within ELF, I'd say.

And global state isn't the big problem, that I can see, but global
information, such as errno, and global files, such as stdin, stdout and
stderr. State variables are tied to the code, and if you run separate
code, with separate state variables, you get no conflicts, even though
both sets might be doing the same thing. It's just inefficient.
(Someone will probably prove me wrong 3 seconds after I post this. :-)

> Unfortunately, migrating to dynamic linked base system doesn't
> completely solve this problem (althought it certainly decrease the
> problem). The only way to correct this problem is to unsupport
> statically linked binaries (e.g. rm /usr/lib/lib*.a). And that's
> what I don't like. ;)

We really don't want to move in that direction, I think.
It seems like feeping creaturism to me. We are so intent on supporting
dlopen() that we rather risk breaking the universe.

> Anyways, as written by Giles Lean in above message, supporting
> dlopen() for static binaries is not really worth doing.

That's more than I could read from it.

But if so, then I have another suggestion.
Duplicate /bin and /sbin in /usr/bin and /usr/sbin, and have them
dynamically linked there. That would also mean that users paths could skip
/bin, which in itself is a boon, since the path variable cannot be
arbitrarily long.

How about that?

	Johnny

Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt@update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol