https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017
Bug ID: 78017 Summary: weak reference usage in gthr-posix.h (__gthread*) is broken Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: nsz at gcc dot gnu.org Target Milestone: --- there seem to be no open bug for the issue discussed in https://gcc.gnu.org/ml/libstdc++/2014-11/msg00122.html i think libstdc++, libgfortran and libgcov are affected. libgcc/gthr-posix.h uses weak references for the pthread api to 1) detect single-threadedness 2) use pthread api without adding -lpthread dependency. this does not work a) with static linking: because 1) fails on the target: single threaded execution can be assumed if pthread_create and thrd_create are not referenced (on targets without libpthread dlopen support), but the gthr logic only checks pthread_create (on bionic) or pthread_cancel (on some targets as a misguided attempt to avoid detecting threads because of ldpreloaded pthread wrappers which "seem unlikely" to define pthread_cancel). symbols required by libstdc++ may be missing because of 2), (causing hard to debug runtime crashes): redhat puts all of libpthread into a single .o, others use -Wl,--whole-archive -lpthread -Wl,--no-whole-archive linker flags as a workaround, but this should not be needed: if libstdc++.a semantically requires strong references then those references must be strong (the calls may be elided using the detection above). b) if there is dlopen support for libpthread then single-threadedness can change at runtime, so any check would break code like std::mutex m; m.lock(); dlopen(.. something that starts threads and use m ..) m.unlock(); various targets explicitly opt out from the weak ref hacks, (using gcc configure time hacks), i think instead the gthr logic should be safe by default: assume multi-threaded execution by default and only try to optimize the single threaded case when it is guaranteed to be safe.