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

[Florian Weimer <fweimer at redhat dot com>]

* Florian Weimer:

> * 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
> [occur] in paths.  At that point, you will be hard-pressed to
> implement this processin[g] using shell scripts.

With “this processing”, I mean adding new entries to LD_LIBRARY_PATH,
for example.

>> 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
>>      https://12factor.net/config
>
> What's missing from the envz functions?

Can we please move the discussion forward?

Thanks,
Florian