Re: rtld + static linking

Marcel Moolenaar wrote:
> > Ether way, you still need to deal with the linker changes necessary
> > to export the symbol set for all statically linked objects, and to
> > force the inclusion of all archive members when statically linking,
> > if one of the linked libraries is libdl, if you wanted a full
> > implementation.
> 
> I think the cure is worse than the decease in this case. You don't
> want the full libc linked into a static sh, simply because we need
> to be able to load a shared library at runtime.

The alternative is to create a version association between the
libc.a and libc.so, to allow it to be recovered at runtime.  I
don't know how satisfying this would be, but it would resolve
99.9% of the cases, I think.  Arguing against inclusion of
everything for all static libraris without a shared counterpart,
and for the main program, is harder.  For my money, it's a lot
easier to dynamically link everything, and only deal with one
type of executable image thereafter.


> If you can get gcc and binutils to add the necessary support, then
> we can talk further. Until then it's academic.

I think there are political reasons for not doing this.  The
number one reason would be that you could load GPL'ed code as
a module into a non-GPL'ed program, and then use it without
neding to change your own license to GPL.  Editorially, the
FSF compiler folks have some incentive for making dlopen()
inconvenient/difficult to use.  If you link dynamic, at
least they get the LGPL behaviour for all your other libraries
as a consolation prize, so making it work is probably on their
list of "Things To Not Do".

If the Linux people want to be SUSv3/POSIX/IEEE 1003.1-2003
compliant, they'll do the work and FreeBSD will get it for
free.  If thy don't want to do the work, FreeBSD will have to
decide whether they want to carry around local patches, or if
the feature (killing off static vs. dynamic bikesheds) is
worth the effort.

I'm just offering a potential option that's not one of the two
hotly contested ones, as a less controversial approach to a
solution to the original problem.  It's the solution that was
chosen for the original problem that has everyone up in arms,
so a different solution seemed to be called for here...


> > BTW: IEEE 1003.1-2003 requires a full implementation of dlopen, and
> > does not permit an exception for statically linked binaries:
> >
> > http://www.opengroup.org/onlinepubs/007904975/functions/dlopen.html
> 
> Yes it does:
> 
> \begin{quote}
> ... Implementations may also impose specific constraints on the
> construction of programs that can employ dlopen() and its related
> services.
> \end{quote}

The phrase "constraints on the construction of programs" sounds
to me like you're allowed to require compile options, not you're
allowed to make it not work as it's documented to work otherwise,
or we might as well say that calling dlopen() in a given system's
implementation is allowed to invoke nethack, like the original
GCC implementation of "#pragma" did.  8-).


> > I'll also point out that the ELF specification does not define static
> > linking *at all*.
> 
> I think that's because it doesn't need any special mention.

Well, it specifically mentions being able to do something like
linking libc to libresolv, so that you implicitly get the resolver
library when you explicitly link in the C library.  That doesn't
work with static linking of ELF binaries, so I think we can either
say static linking is completely broken and needs to be fixed before
it is allowed to be used, or static linking is undefined by the ELF
standard.


> Note that staticly linked executables can be in violation of platform
> runtime specifications.

A good reason to outlaw them: undefined behaviour sucks.

-- Terry