Date:        Tue, 27 Aug 2002 13:22:03 +0200 (CEST)
    From:        Johnny Billquist <bqt@update.uu.se>
    Message-ID:  <Pine.LNX.4.21.0208271306350.4943-100000@Tempo.Update.UU.SE>

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

Almost anything is possible, a very small subset of that is practical,
an even smaller subset is reasonable as well.

  | What we (I) want is dlopen(), and yet static linked binaries in the root.

The former I understand, your particular justification for the latter
I don't.

Greg Woods I understand, he simply hates dynamic libraries everywhere.
I don't agree, but at least that's a consistent position.

You on the other hand want dynamic binaries in /usr/ and static ones
elsewhere, where the division between what is in /usr and what isn't
is largely completely arbitrary (someone once needed something in
single user mode, so it is in /bin, no-one bothered to remove it - like
I guess that someone knows why chio is in /bin or why setkey or ping are
in /sbin (setkey I can guess at) but some of this is arbitrary.

There's no issue with a recoverable system, the rescue stuff is there
for that.

If it is performance, then the right solution, as others have pointed out
is to improve it, not to simply refuse to go near it.   There could be
lots of things that might be done to make performance better (perhaps
even re-inventing a use for the sticky bit) for standard dynamic libraries,
and if so, that would benefit all the commands that live in /usr/bin as
well (and all of those X binaries with their thousands of shared libraries).

But that doesn't seem to be your argument.   You just don't seem to like
things to be different than what you're used to.   That's crazy.  Even more
so when some of the things that you're insisting that you don't want
(for no reason at all I  have seen) are in fact changes from the way the
world used to be (not having a /lib is a relatively recent invention,
libc always used to be there, and all the other important libraries, even
before static linking was invented).

  | 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.

That's a quite different problem than the earlier one.

  | I can't really see why this should present any problems, be that hard to
  | understand, or be anything but the really correct solution.

You haven't figured out how the dynamic library gets to use the static
programs variables yet.    Aside from the ones that have been mentioned
(errno, the FILE stuff etc) there's all the malloc stuff.   There the
library can't just use its own version and hope, as it might easily be
returning malloc'd date to the application, that the application has to
free (and just to make it clear, the malloc & free have to work together).

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

Go ahead and implement it.   Once you have it working, and all the
problems solved, then tell everyone how it was done, and make the code
available, and if it is good, I suspect it will get adopted.

But you get nowhere telling people who have looked at the problem, for
a long time in some cases, that the solution they couldn't find must
exist, and they have to go and implement it.

kre