This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] deprecate libnsl/libnss_*
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Thorsten Kukuk <kukuk at suse dot de>, libc-alpha at sourceware dot org
- Date: Thu, 7 Apr 2016 17:33:27 +0200
- Subject: Re: [PATCH] deprecate libnsl/libnss_*
- Authentication-results: sourceware.org; auth=none
- References: <20160404134356 dot GA20216 at suse dot de> <5702780D dot 7070208 at redhat dot com> <20160404142237 dot GA20583 at suse dot de> <57062C77 dot 1080103 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1604071516070 dot 26336 at digraph dot polyomino dot org dot uk>
On 04/07/2016 05:25 PM, Joseph Myers wrote:
> On Thu, 7 Apr 2016, Florian Weimer wrote:
>
>> libtirpc also pulls in a lot of libraries, which makes it less
>> compatible with in-process NSS modules. I think it is generally assumed
>
> If it's visible to an application what libraries were loaded by an NSS
> module, I'd consider that to be a bug (bug 16881, I think) - NSS modules
> should be loaded in such a way that this is not visible.
I'm not sure if the general case is solvable. Some libraries want to be
loaded only once, others have to be loaded multiple times in different
versions, and so on. But I expect we can provide additional knobs to
improve the situation.
>> problems due to the additional libraries which it brings in, and the
>> late loading of libpthread (in response to a NSS request).
>
> I think we need to fix the issues in libc that break with late loading of
> libpthread, so that it can be properly transparent to the application
> whether any modules it loads use threads or not. (Bug 16628, I think;
> also bug 18192 relates to dlopen of libpthread, and there may be other
> such bugs filed as well.)
Agreed, this problem seems tractable.
Florian