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:
> I also do not think that LD_* is reserved for glibc, we now have shared
> semantics with musl, and soon llvm's libc, and I fully expect they will create
> their own environment variables here with an LD_* prefix. This means that we
> might be removing env vars that are used by musl or llvm-libc and we should not
> do that.
Sure, it's a shared namespace, like pretty much everything else. I'd
love to coordinate such changes across libcs, but we don't have such a
>> 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.
> One already has to have a sufficiently complex parser to handle : splitting,
> along with spaces and escaping, extending the parser to handle N=V is no
> that much additional complication. In-line editing of LD_LIBRARY_PATH via
> shell is not trivial, but setting and unsetting is easy.
We'll need string quoting because any option separator we choose can in
paths. At that point, you will be hard-pressed to implement this
processin using shell scripts.
> I would *support* making APIs to properly handle env-var => array, and
> array => env-var support, so one can insert into LD_LIBRARY_PATH or
> GLIBC_TUNABLES easily from a C API.
> e.g. https://github.com/sloria/environs
What's missing from the envz functions?
>> 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.
> Exactly! I was just going to suggest this, because if the use case is
> designed for this exact scenario then the developer of the shim can
> build the shim in a certain way to make it easier for the user.
> The semantics of the new DT_ tag would be interesting, because we could
> do something like:
> Encoding at least some of the .gnu.version_r information in DT_VERSIONS
> to allow us to make the error checking more robust.
> This is just a thought.
I'll have to verify that this actually works out with the order things
are processed in the dynamic linker.
If it's more than a flag, I think we'd need a new data structure because
we have two arbitrary strings, soname and symbol version, and no clear
way to separate them.
>>> (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.
> I don't follow, could you expand on this a bit, or verify that I understand
> you correctly?
> A Solaris-style version is where we have possibly one version recorded
> per library, and it's the oldest version that covers the called APIs.
> Which could be implemented as just having .gnu.version_r entries without
> the associated symbol versions? Right?
> I have never seen a Linux-based implementation of this, but I agree that
> removing the check entirely would not support such an alternative use.
binutils has some remnants there. I have never used it.
> I think the real question is this:
> Do we avoid the env var and try to implement it all as a DT_* tag?
For something that's just a hack to avoid rebasing glibc? I don't think
so. I suspect everyone would be better off if we could deliver
functionality provided by newer glibc versions in more direct ways.
A mere flag in DT_* might hit a sweet spot in terms of implementation
complexity and user convenience, though.