This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Provide pthread_atfork in libc_nonshared.a and libc.a.
- From: Rich Felker <dalias at aerifal dot cx>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>
- Date: Thu, 3 Oct 2013 10:07:10 -0400
- Subject: Re: [PATCH] Provide pthread_atfork in libc_nonshared.a and libc.a.
- Authentication-results: sourceware.org; auth=none
- References: <524C90A1 dot 6050801 at redhat dot com> <524CC8BA dot 6050602 at redhat dot com> <20131003052910 dot GV30970 at tucnak dot zalov dot cz> <20131003061602 dot GI20515 at brightrain dot aerifal dot cx> <20131003061827 dot GW30970 at tucnak dot zalov dot cz>
On Thu, Oct 03, 2013 at 08:18:27AM +0200, Jakub Jelinek wrote:
> On Thu, Oct 03, 2013 at 02:16:02AM -0400, Rich Felker wrote:
> > The weak references are just wrong. Instead, the library should have
> > strong references to symbols with weak _definitions_ in either (a
> > hypothetical dependency) libpthread_stubs.so or libc.so that do
> > nothing, and that get overridden by the strong definitions in
> > libpthread.so. Or we could just do away with the silliness of having
> > these functions in a separate .so file, make libpthread.so a stub, and
> > put everything in libc.so. For this to work for glibc, though, a lot
> > of mess with symbol versioning would be needed. In musl, it was easy.
> Feel free to do it in musl if you like it; though, this constant musl
> marketing IMNSHO doesn't belong to this list.
I'm sorry if you feel there has been any "constant marketing" from me.
In the above quoted text, the mention was not strictly necessary, but
I don't believe it was "marketing", just an expression of the contrast
between my experience implementing the above and what would be needed
to do similar in glibc.
As for other mentions, AFAIK they have all been in the context of
design for things like safe TLS preallocation which are mildly complex
to implement but which already have working implementations in musl,
and again the purpose for mentioning that has been to offer proposed
designs that work, along with ideas for what differences might be
needed in adopting a similar design in glibc.
If others feel like this is "marketing" that's unwelcome, please let
me know. I thought it was contributing to the improvement of glibc.