Re: rtld + static linking

On Tue, Nov 25, 2003 at 05:44:18PM -0800, Terry Lambert wrote:
> "E.B. Dreger" wrote:
> > After watching the recent shared/dynamic threads, and reading the
> > archives from five or six years ago, I have a question...
> > 
> > Dynamic linking works by the kernel running the dynamic linker,
> > which loads shared objects and fixes the symbol tables, yes?
> 
> No.
> 
> Dynamic linking works because the crt0 mmap's the /usr/libexec/ld.so
> file as executable, and then points known stub offsets into it.

No.

Dynamic linking works because the kernel loads and runs the dynamic
linker when it sees that the executable defines an interpeter.

> > Is there some reason that a statically-linked program couldn't
> > include some "ld-elf.a" type of intelligence?  Would that be
> > necessary and sufficient to allow statically-linked programs to
> > load shared objects?
> 
> Yes, and yes.

No, and no.

A complete executable (i.e. staticly linked) does not export any
symbols, or at least not in the same way a shared executable and
shared libraries do. If I try to dynamicly link libbar into a
complete executable foo and libbar depends on libc, then there's
no guarantee that all the required bits from libc are in foo, nor
is there any guarantee that the bits are actually visible or even
accessable (no linkage table).
Dynamicly loading libc for use by libbar can work, but it's not
guaranteed. One failure mode is suddenly having two instances of
a common variable instead of one. Another is the clobbering of
data caused reinitializations.

So, the problem of dynamic linking a shared library into a static
process is non-trivial and probably cannot be solved genericly.
Under restricted and controlled conditions you can make it work.
I would call it the ability to have plugins, not the ability to
load dynamic libraries.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel_at_xcllnt.net