[Bug libstdc++/67791] Crash using std::thread and iostream with dynamic loading of a shared library

["nexyon at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67791

--- Comment #4 from nexyon at gmail dot com ---
Thanks for the quick responses! I already expected some sort of side effect
like this. Maybe it's possible to reevaluate whether pthread is linked or not
during the first use of std::thread? In any case std::thread should not crash I
guess, so just to fix that it would be necessary to check whether the standard
library was inizialized without threads. Or shouldn't there be locks in any
case? What if another threading library is used but pthreads, that libstdc++ is
not expecting? (Not sure though, how practical that is, or how likely that's
going to happen)

As the problem seems to be known, I wonder if I can expect this to be solved
any time soon? For now I guess my options are to tell the users of my library
and it's plugins to always link pthread to their main program or maybe
artificially add a function in my library that uses std::thread so that my
library gets linked against pthread. Then linking dynamically with it in the
executable should not cause problems, only symloading the library would still
cause the same problem. Or do you have other ideas?

Cheers!