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: Roland McGrath <roland at hack dot frob 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>, Jakub Jelinek <jakub at redhat dot com>
- Date: Wed, 2 Oct 2013 14:56:00 -0700 (PDT)
- 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>
> This idiom is completely wrong; it does not work with static linking.
Indeed. Yet we are stuck with it because libstdc++.a is compiled as PIC
that does this. That is not just a matter of getting GCC folks to fix
their build. They are actually trying to support -static-libstdc++
-shared for making a DSO that uses libstdc++ internally but does not
want to have a SONAME dependency on the particular libstdc++.so version
it built with. So until we work out a way to address that problem
that's acceptable to the GCC/libstdc++ maintainers, there isn't much
point in getting too excited about the libc end of the problem.
> Programs which are using this approach need to be fixed. We've also
> run into it (much more heavily) with musl libc, where unlike in glibc,
> the pthread .o files in libc.a are well-factored so that only the
> code the program needs gets linked.
On the whole, glibc's .o files are well-factored. (It was a static-only
library first, after all.) There are exceptions due to past laziness
that should be fixed, but a broad statement like this is not fair (I
don't expect you to be fair to glibc when you're making claims about how
musl is so awesome, but I expect you to expect pushback to your claims
;-). Moreover, distros such as Fedora (maybe most?) are using a patch
that ld -r's most of libpthread's .o's into one, precisely to work
around the static linking vs libstdc++ weak references issue (at the
cost of lots of dead libpthread code in statically linked binaries--but
given the amount of dead code in binaries statically linked with libc.a
anyway, which are mostly due to excessive hairy interdependencies and
dubiously useful dynamicism support for gconv and the like in static
binaries, not to poor factoring of .o's per se, the incremental dead
code addition in libpthread is hard to get too exercised about).