https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67791
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2020-11-23
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to nexyon from comment #4)
> 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?
No, because the result is cached in a static const variable, which can't be
changed after its first use.
> 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.
We used to check for the pthread_create weak symbol, and throw an exception
instead of crashing. Since the fix for PR libstdc++/61841 we don't check it,
and crash instead of throwing. That should be fixed.
> 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)
That's not supported. The only supported way to create new threads is via
pthreads.
> 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
Right.
> 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?
If the main executable is not linked to libpthread, using dlopen to load a
library that depends on libpthread doesn't work. This is currently unsupported,
and unsupportable on GNU/Linux.
If your library depends on libpthread.so and the main executable links to your
library that should be fine. You don't need to use std::thread for that, just
link to it without using --as-needed e.g. -Wl,--no-as-needed -lpthread
-Wl,--as-needed
Late-loading of libpthread.so via dlopen should start working with a future
version of glibc, when this is implemented:
https://sourceware.org/legacy-ml/libc-alpha/2019-10/msg00080.html
