This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] ld.so: Enable preloading of new symbol versions [BZ #24974]
* 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
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
> - 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.