This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: 2.25 freeze status
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, 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 11:06:02 -0500
- Subject: Re: 2.25 freeze status
- Authentication-results: sourceware.org; auth=none
- 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> <5891F73B.6060203@arm.com>
On 02/01/2017 09:56 AM, Szabolcs Nagy wrote:
> 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.
We want dlopen from a static executable to work.
There are some things that don't work, but I consider those bugs
we need to solve anyway to get dlmopen working (the static->dynamic
namespace issues are the same issues present in the ns1->ns2 namespace
issues).
Both dlopen from a static executable and dlmopen are important features.
--
Cheers,
Carlos.