Anders Magnusson <ragge@ludd.luth.se> wrote:
> Eh, the kernel has nothing to do with shared libraries.
   
   Really? Let's say someone calls execve(2) on an executable that requires
some shared libs. The kernel will pull in the executable itself, but it
also needs to pull in the shared libs, right? Or are you saying that it
doesn't? Are you saying that the kernel pulls in only the executable
itself, and the code to pull in the shared libs is inside it (put in there
by the toolchain at build time)? I have never thought of this approach...
If this were true, it would very easy to explain why the hp300 and sparc
ports of 4.4BSD can run native HP-UX and SunOS binaries which require
shared libs, even though Berkeley UNIX(R) apparently has never used them
itself (and sure enough, 4.4BSD's toolchain cannot generate them).
   
   [A side note.] I know for sure that 4.4BSD doesn't use shared libs, and
I have always thought that 4.3BSD is no different. However, the total size
of all system binaries increases by a factor of 3 between 4.3BSD-Tahoe and
4.4BSD (dunno about Reno and Net/2). This change is so drastic that I have
a hard time explaining it without the theory that 4.3BSD did use shared
libs after all. The toolchain has changed almost completely between 4.3BSD-
Tahoe and 4.4BSD and the new one hasn't been polished very well because
CSRG has been disbanded too soon, so it's conceivable that there was
support for shared libs before but it has been broken by the new toolchain.
Or maybe this theory is wrong, and the 4.4BSD binaries are simply bloated
because of the POSIXisation and "renovation" dehancements. Would someone
knowledgeable please enlighten me? I don't have a copy of 4.3BSD yet to
check for myself.
   
   And what about Ultrix? Does it use shared libs? I know SunOS does.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu