On Mon, 26 Aug 2002, Bill Studenmund wrote:

> On Mon, 26 Aug 2002, Johnny Billquist wrote:
> 
> > I still (and always will) think that dynamically linking /bin and /sbin is
> > a very lousy idea. If people want locale support I don't object to
> > that. What I object to is dynamic linking in the root. It plainly
> > stinks.
> 
> We can't do both. As other posts have indicated, programs need to be
> dynamically linked in order to safely/sanely dlopen() things. locale
> support really means dlopen() of locale code.

I was thinking about this is the shower this morning (for some reasons
showers is a place where I manage to think about things).

I actually do think it is possible (well, actually, *anything* is
possible).

What we (I) want is dlopen(), and yet static linked binaries in the root.
The reason is locale, and perhaps other "nice" loadable features in the
future.
The problem is (correct me if I'm wrong) that we get problems since
dynamically loaded stuff might want to load yet other dynamic stuff, which
might conflict with the static linked stuff.

But how is this resolved in a dynamic linked binary? The same thing can
obviously happen there. You can have two libraries loaded, which both
refer to a third library in turn, and they want different versions of that
third library.

I assume this have been solved, and that dlopen() knows which version is
loaded, and if a conflicting load is requested, things fail.
(If this haven't been fixed we really are deep in the shit already.)

So what we need for static linking to work is that dlopen needs to know
the versions of the statically linked libraries, and make the same checks
as usual.
Put in another way: statical binaries shouldn't be any different than
dynamic binaries in which the same libraries that were linked in the
static case have already been loaded in the dynamic case.

I can't really see why this should present any problems, be that hard to
understand, or be anything but the really correct solution.
(Heck, I'm back where I was at the start. dlopen() should be available for
static binaries as well.)

This is definitely a bit more difficult to implement than just switching
everything to use dynamic linking, but I consider it the "right way".

Static binaries is a good thing sometimes, and dlopen() is still a good
thing sometimes, so we really should provide the possibility for both.


> > The bottom line is: find a better solution, and wait until that is
> > implemented.
> > You're taking the easy (and lousy) way out right now.
> 
> This _is_ the best solution. It's not the easiest, it is the only one.

No. We're talking computers. There is never an "only" way when you talk
about implementing things.

> In order to do what we want to do, we have to be able to dlopen() in
> programs in /{,s}bin. dlopen() means dynamic. Thus to do what we (the
> NetBSD project developers) want to do means /{,s}bin dynamic. It really is
> that simple.
> 
> We looked for other solutions. There are none (well, all the ones we found
> are worse than this one).

I consider my above suggestion to be a better solution, if not simpler.
dlopen() means dynamic (that's pretty obvious from the name, isn't it?),
but it don't mean you have to remove the possibility of static linked
programs.

> Suggestions on how to better do this are appreciated. But, "This is
> stupid," won't cut it, since we think the things this change lets us do
> aren't stupid. :-)

I'm trying as hard as I can.
My bottom line is that while dlopen() is nice, and we want it, static
linking is also nice, and we want it.
I'll continue to insist that there are ways to keep both, while you seem
to opt to remove one of them for a fast and easy solution. :-)

I'll try to refrain from using the word "stupid" if it makes you
happy. ;-) :-)

	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