This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What to do when glibc environment variables or tunables conflict?
- From: Siddhesh Poyarekar <siddhesh at gotplt dot org>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: Carlos O'Donell <carlos at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Joseph Myers <joseph at codesourcery dot com>, Florian Weimer <fweimer at redhat dot com>
- Date: Thu, 6 Feb 2020 17:13:06 +0530
- Subject: Re: What to do when glibc environment variables or tunables conflict?
- References: <06dd0f65-3a65-b565-d321-aabccd2e3c4c@redhat.com> <b19320d8-9ad6-d5a1-4121-b5c67902a9e1@gotplt.org> <mvmeev8jcoe.fsf@suse.de>
On 06/02/20 14:49, Andreas Schwab wrote:
> On Feb 06 2020, Siddhesh Poyarekar wrote:
>
>> On 06/02/20 03:42, Carlos O'Donell wrote:
>>> Explicit use of LD_BIND_NOW=1 or LD_DEBUG=unused disables ld audit
>>> because both uses set GLRO(dl_lazy) to zero and disable lazy binding
>>
>> LD_DEBUG doing that is a bug.
>
> I disagree. LD_DEBUG=unused is for probing, and doesn't even run the
> object. So auditing doesn't come into play.
Ahh, I stand corrected for this. But in that case it should not get in
the way of LD_AUDIT, should it?
>> To expand on LD_DEBUG, it should be the lowest priority.
>
> No, it should be highest priority. It's a debugging device, so it needs
> to be honored to be useful.
The context of my comment is when LD_DEBUG changes behaviour and
conflicts with other options.
Siddhesh