This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus: Tuning runtime behaviour with environment variables.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Stephan Bergmann <sbergman at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Andreas Jaeger <aj at suse dot com>, "Ryan S. Arnold" <ryan dot arnold at gmail dot com>, Andi Kleen <andi at firstfloor dot org>, David Miller <davem at davemloft dot net>, Siddhesh Poyarekar <siddhesh at redhat dot com>, Andreas Schwab <schwab at suse dot de>
- Date: Wed, 29 May 2013 17:46:56 -0400
- Subject: Re: Consensus: Tuning runtime behaviour with environment variables.
- References: <51A58A92 dot 4050508 at redhat dot com> <51A5A99A dot 8020508 at redhat dot com> <51A6219B dot 9070007 at redhat dot com> <51A62C04 dot 1030801 at redhat dot com>
On 05/29/2013 12:25 PM, Stephan Bergmann wrote:
> (The example of LD_LIBRARY_PATH also indicates that what is required
> is not always functionality to clear the env, but sometimes it is
> functionality to reset an env back to a state before it got
> overridden.)
Your description sounds more like a broken test setup than anything
that should impact the use of env vars for tuning runtime behaviour.
The problem with LD_LIBRARY_PATH is that it changes program semantics,
and therefore has to be carefully carried into all the places that
need it (really a fault of the test system for not modelling invocation
of AUT as a shell+env+command+args+files).
The tuning write up forbids changes to semantics, so LD_LIBRARY_APATH-
like env vars would not have been accepted.
> It's fun like that which prompts me to point out that general problem
> with env vars. But for your specific question, I fear I need to
> chicken out. I see both the pros and the cons, and I'm not sure what
> an ideal solution would look like,
OK, putting down an abstain.
Cheers,
Carlos.