Unfortunate dynamic linking for everything

[Michael Edenfield]

* Tim Kientzle <kientzle at acm.org> [031121 18:40]:
> Leo Bicknell wrote:
> >To boot a machine into single user mode you need a kernel, init,
> >and /bin/sh (minimally).  It would seem to me that alone is a good
> >argument for those three things to be static.

>  * Rewrite dlopen() to not require dynamic linking.
> 
>    There were some patches for this submitted at one point.
>    As I recall, the people who looked at them were not entirely
>    comfortable with them.  (I'd be concerned about version
>    conflict problems with this approach:  what happens when
>    a dynamically-loaded NSS module refers to a libc function?
>    Does that get resolved to the already statically-linked
>    version?  Or does another copy of libc get dynamically linked
>    with potential version conflicts?  Does anyone know?)
> 
>    I personally think this is worth researching, though I
>    have my doubts.

I took a look at the glibc implementation of dlopen() breifly, since
that does function from within libc.a.  It appears that you *do* get
more than one loaded copy of libc.  The copy of dlopen() that is built
when #ifndef SHARED includes a flag: __libc_multiple_libcs that is set
to 1.

Additionally, I was reading comments from some of the glibc developers
who basically claim that dlopen() in a static binary *only* works if you
dlopen() a NSS module.  It isn't guaranteed to work in the general case
because the static binary has no DYNAMIC elf section to resolve external
references etc.  I suspect this means NSS modules are limited in what
they are allowed to reference and still work?  I haven't looked in much
detail on their implementation but it certainly looks like a hack just
to make NSS work, which I don't think is a good long-term solution.

--Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20031122/31c0a13d/attachment.bin