This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC 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: Linking with -pthread only if linking with a .so that needs it


Jonathan Wakely writes:

On 24 April 2018 at 12:14, Sam Varshavchik wrote:
> I'd like to to understand a little bit better why it seems that I need to
> use -pthread to compile and link something that does not use execution
> threads, std::locks, or std::mutexes, but it links with several shared
> libraries that do. Without -pthread the link appears to be fine, but then I
> observe some instability in the initial static initialization, before
> main(), in those shared libraries' static initialization code.

Without looking into it in much detail, this could happen during a
static constructor in a shared library (or if you dlopen libpthread,
but it doesn't looks like you're doing that).

Right. This is is a static constructor in the shared library.

If the main application is not linked to libpthread then during
initialization of its global variables __gthread_active_p() will
return false. While loading your shared library libpthread.so gets
opened, and after that point __gthread_active_p will return true.

But that static constructor is in the shared library that's linked with libpthread. The static constructor did a std::mutex::lock followed by std::mutex::unlock, and it seemed like only the unlock thought libpthread wasn't linked in. lock() incremented the counter in the mutex, and put its pid in there. unlock() left the mutex untouched, leaving it in locked state.

No threads were created at that point, during initialization. The app code in question does not create threads until main() runs.

Attachment: pgph7o9O9zsAE.pgp
Description: PGP signature


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