Re: [PATCH] Provide pthread_atfork in libc_nonshared.a and libc.a.

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Oct 02, 2013 at 02:56:00PM -0700, Roland McGrath wrote:
> > 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.

You're saying libstdc++ is using things like:

    if (pthread_mutex_lock)

to determine if locking is necessary? Or something else?

> 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.

I don't see why incorrect use of weak references to pthread functions
is required for libstdc++.a to work properly.

> > 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

Then why does static-linking a trivial hello app give a 500+ kB
binary? My experience is that isolated, small files are well-factored,
but the big components (stdio, locale, pthread, etc.) are such that a
single reference to a single symbol pulls in all modules from the
whole subsystem. Of course, this is only approximate; in the case of
pthreads, some symbols are _not_ pulled in, which causes the
application bug (weak references to pthread functions combined with
static linking) to manifest.

> 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
> ;-).

The screenshot on our freecode (formerly freshmeat) listing backs
these claims (static linked hello world with pthread in ~15k). :)

> 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).

Yes, they're working around the application bug by patching glibc to
behave the way applications wrongly expect it to behave...

Rich