I've been deleting sokolov's messages almost reflexively, but this is
so off-base I'm afraid someone else might be misled by it.

>> Eh, the kernel has nothing to do with shared libraries.
> Really?

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?

Wrong.  Or more precisely, yes, the kernel is involved, but only in the
sense that the kernel is involved in any I/O done by a user process;
when the kernel brings in a shared library, it doesn't know that it's a
shared library, all it knows is that userland asked to read (or mmap or
mprotect or whatever) that file (or region of memory or whatever).

> 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)?

Exactly.  SunOS does it this way, NetBSD does it this way.  I don't
know enough about any other OSes with shared libraries, but I'm sure
there are others that do it this way.  crt0 checks to see whether ld
marked the executable as dynamically linked; if so, it brings in ld.so
and calls on it.  ld.so then searches out the relevant libraries, maps
them in, does any relocations ld couldn't do, and at run time, snaps
the pointers to dynamically-linked routines as they get their first
calls.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B