This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] 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
forum today.

>> 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.

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:
> DT_PROVIDE_VERSIONS=",GLIBC_2.19:libpthread=GLIBC_2.18,GLIBC_2.19"
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]