On Sun, 2016-04-10 at 13:35 -0700, Russ Allbery wrote:
[...]
> The major place where this breaks down is with shared
> libraries, since, due to how dynamic linking works, even shared libraries
> only used in specific dconfigurations have to be listed in Depends. But,
> because the shared library may be unused other than by mapping it during
> process startup, all of its dependencies (of any strength) that don't
> interfere with startup mapping should be deprioritized.
>
> In other words, the root of the problem is that we're forced to take
> artificially strong dependencies that aren't warranted by the
> functionality of the library due to the implementation of dynamic linking
> and the fact we want startup binding instead of lazy binding on first call
> (for some justifiably good reasons).
Binding *is* lazy by default, but loading of NEEDED libraries is eager
since ELF dynamic symbol references don't say which library they're
expected to be resolved in (perhaps the best *and* worst feature of ELF
dynamic linking). If we made the absence of a NEEDED library non-
fatal, that would put off failure until the application used a symbol
from the missing library, but at that point I don't think there's any
good way for the application to handle failure gracefully.
Would it be useful to have a linker option to omit a NEEDED entry for a
particular library? The application could then call
dlopen("libfoo.so.42", RTLD_NOW|RTLD_GLOBAL) before it starts using the
library, typically right before calling foo_init(), but it wouldn't
need to use dlsym(). However this would absolutely depend on lazy
binding, i.e. the application would break if LD_BIND_NOW was set.
Ben.
--
Ben Hutchings
Humans are not rational beings; they are rationalising beings.Attachment:
signature.asc
Description: This is a digitally signed message part