This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]