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: Jakub Jelinek <jakub at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- 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: Wed, 2 Oct 2013 23:42:55 +0200
- 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> <20131002213604 dot GW20515 at brightrain dot aerifal dot cx>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Oct 02, 2013 at 05:36:04PM -0400, Rich Felker wrote:
> On Wed, Oct 02, 2013 at 05:31:13PM -0400, Carlos O'Donell wrote:
> > The standard design pattern for making it optional to link against
> > libpthread is to mark the function weak, test if the function
> > address is non-zero and call the function, otherwise use a fallback.
> This idiom is completely wrong; it does not work with static linking.
No, that idiom is not wrong, is pretty standard practice for many years,
e.g. libgcc, libstdc++ etc. use it heavily and GCC/binutils extensions
have been designed for it (weakref).
Static linking is much less important than dynamic linking, and forcing
libpthread upon everybody that uses some shared library that should be
thread aware but doesn't really require it is just a bad idea.
There is really no cost in making pthread_atfork not require -lpthread,
because __register_atfork is implemented in libc already.