On Mon, 7 Jan 2002, Wolfgang Solfrank wrote:

: The need to link against "libplacebo" is the result of ld not
: creating the dynamic symbol section for static binaries.  This could
: easily be changed.  I'd even go as far as calling it a bug that ld
: doesn't create this section when using the "-E" switch, as this switch
: explicitly tells ld that I do want a dynamic symbol section (note that
: I didn't test this).

I'm not entirely sure that doing this will be easy, but read on.

: If you are pointing to the problem that changing the ABI of a global
: symbol requires at least relinking any of those "static" binaries,
: then yes, I think I agree.

That's pretty much the concept I was trying to illustrate.

: > [*] Even so, if the programs are dynamically linked, what's the difference
: >     between going through all these linking headaches and simply linking
: >     against a shared libc?  In the former case, you still have to link
: >     with a library that may be corrupted (even if just a "libplacebo"), and
: >     in the latter case, you gain the ability to fix libc bugs simply by
: >     replacing libc.

: It should be quite easy to write a static dlopen() which would, on its
: first call, load ld.elf_so and initialize it before loading the actual
: shared object given as argument.

"You don't do that."  That's a.out thinking at work.  8-)

The ELF spec is very explicit on how the dynamic linker is initialized -- it
must be named by the binary as the ELF "interpreter", and is initialized and
called by the kernel *before* the main program ever gets control.
(ld.elf_so then, in turn, calls the main program.)

Now, that doesn't mean you *can't* do that, only that it'd be a very gross
hack, and IMHO not worth the effort of maintenance vs. simply linking
against libc.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/