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]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 02 Oct 2019 13:36:26 +0200
- Subject: Re: [PATCH] ld.so: Enable preloading of new symbol versions [BZ #24974]
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
* 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,
>> 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?
Can we please move the discussion forward?