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!
