This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: 2.25 freeze status
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: <nd at arm dot com>, Florian Weimer <fweimer at redhat dot com>, Siddhesh Poyarekar <siddhesh at gotplt dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Wed, 1 Feb 2017 14:56:59 +0000
- Subject: Re: 2.25 freeze status
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <c4cfc6e1-ff9f-c8b3-4a56-38f8d484aa05@gotplt.org> <627e42c4-4bf4-e297-2f06-a32ea9698192@redhat.com> <588B74E3.808@arm.com> <f2ee2fed-3430-d9a9-3cee-64a8626e2905@redhat.com> <or8tpqe50g.fsf@lxoliva.fsfla.org> <5891BA4A.4010507@arm.com> <or37fydl3f.fsf@lxoliva.fsfla.org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 01/02/17 14:47, Alexandre Oliva wrote:
> On Feb 1, 2017, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>> _dl_update_slotinfo_list is called
>
> guarded by #ifdef SHARED. Do you see it called in some other path
> within the to-be-statically-linked dl_open_worker? If not, this assert
> could fail not just when users called dlopen in statically-linked
> programs, but even when they called functions that rely on dlopening
> internally (nss comes to mind).
i assumed dlopen in a static linked program is
unsupported (as it is broken when it is deployed
to a system with different libc which is the
main use of static linking)
if that's supposed to work then i agree that
both dtv setting hunks should be reverted.