Re: [PATCH] ld.so: Enable preloading of new symbol versions [BZ #24974]

[Florian Weimer <fweimer at redhat dot com>]

* Carlos O'Donell:

> (a) Not a tunable, but use some tunable framework.
>
> I assume this isn't a tunable because it changes the semantics of the
> dynamic loader.
>
> I would like us to avoid adding another env var since it will become
> another variable that downstream needs to learn to "clean" from the
> environment if they want to manage runtime behaviour.

We have basically reserved the LD_ prefix for these knobs.  It is
relatively easy to strip all environment variables which start with
"LD_" (very easy if you use posix_spawn or execve with an explicit
envp).

If we stuff everything into a single environment variable, applications
would have to write a parser for the variable contents even if they just
want to add a single directory to LD_LIBRARY_PATH.  This doesn't strike
me as a good idea.

> (b) When does a user know to use this env var?

When application developers who ship a glibc compatibility shim tell
them to.

> - Is one scenario like this:
>
>   - They have an old library that doesn't provide all the symbols they need.
>   - They implement a preload that provides the missing functionality.
>   - They disable the check with an env var and run a newer program using 
>     a mix of the old library and preload to provide all the required symbols.
>
> Is that a valid scenario? We should document something like this in
> the NEWS entry.

The NEWS entry already references this scenario (LD_PRELOAD of new
library versions).  If we had documentation for the dynamic loader, I
would have added it there.

We could also add a new DT_ tag to the LD_PRELOAD library and disable
the check for the process if we encounter such a library.  That would
simplify things for users.

> What other useful scenarios are supported by the change?

I don't know of anything else.

> (c) Why not remove the check entirely?

I don't know if anyone uses Solaris-style versions (without associated
symbols).  They would completely break as a result, in the sense that
the version check for them is completely gone.

Even without that, with lazy binding, users will start to see crashes in
programs if their glibc (or libstdc++) is too old, instead of them
failing to start at all.  I don't think that would be an improvement.

Thanks,
Florian