From: Navin P <navinp0304@gmail.com>
To: "Carlos O'Donell" <carlos@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>, libc-alpha@sourceware.org
Subject: Re: [PATCH] elf: Always set l in _dl_init_paths (bug 23462)
Date: Tue, 9 Mar 2021 11:09:34 +0530 [thread overview]
Message-ID: <CALO2TqJYMqzc2sWciEiaH5KGw=bwCNaaqMw9_F5RuLa-w+12gg@mail.gmail.com> (raw)
In-Reply-To: <725cc7f6-790e-93e4-623e-cc4186deb5ec@redhat.com>
On Tue, Mar 9, 2021 at 4:42 AM Carlos O'Donell via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> On 3/5/21 1:25 PM, Florian Weimer wrote:
> > From: Carlos O'Donell <carlos@redhat.com>
> >
> > After d1d5471579eb0426671bf94f2d71e61dfb204c30 ("Remove dead
> > DL_DST_REQ_STATIC code.") we always setup the link map l to make the
> > static and shared cases the same. The bug is that in elf/dl-load.c
> > (_dl_init_paths) we conditionally set l only in the #ifdef SHARED
> > case, but unconditionally use it later. The simple solution is to
> > remove the #ifdef SHARED conditional, because it's no longer needed,
> > and unconditionally setup l for both the static and shared cases. A
> > regression test is added to run a static binary with
> > LD_LIBRARY_PATH='$ORIGIN' which crashes before the fix and runs after
> > the fix.
> >
> > Co-Authored-By: Florian Weimer <fweimer@redhat.com>
>
> If you have reviewed this patch and find it sufficient this is enough
> consensus IMO to commit the patch.
>
> The technical direction was set by earlier patches where we are working
> towards making static and dynamic linking look and behave in similar
> ways.
>
> Thanks for taking this patch up, working through it, and adjusting the
> testing.
>
> Unless anyone objects I'd commit this patch since it fixes a real bug
> with ldconfig running when LD_LIBRRAY_PATH is set in some way globally.
>
> > ---
> > v2: Adjusted test not to use the test framework. Redid the change from
> > scratch.
> >
> > I think we should revisit testing for static DT_RUNPATH support
> > later, and not as part of this patch.
> >
Does this fix https://sourceware.org/bugzilla/show_bug.cgi?id=27504 also ?
next prev parent reply other threads:[~2021-03-09 5:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 18:25 Florian Weimer
2021-03-08 22:26 ` Carlos O'Donell
2021-03-09 5:39 ` Navin P [this message]
2021-03-09 6:05 ` Florian Weimer
-- strict thread matches above, loose matches on Subject: below --
2019-10-09 0:01 [PATCH] elf: Always set l in _dl_init_paths (Bug 23462) Carlos O'Donell
2019-10-15 16:24 ` Carlos O'Donell
2019-10-16 9:54 ` Florian Weimer
2019-10-16 11:15 ` Carlos O'Donell
2019-10-16 11:23 ` Florian Weimer
2019-10-16 13:31 ` Carlos O'Donell
2019-10-25 1:16 ` Carlos O'Donell
2019-10-25 8:37 ` Florian Weimer
2019-10-25 12:55 ` Carlos O'Donell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALO2TqJYMqzc2sWciEiaH5KGw=bwCNaaqMw9_F5RuLa-w+12gg@mail.gmail.com' \
--to=navinp0304@gmail.com \
--cc=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).