https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Marc Glisse <glisse at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |glisse at gcc dot gnu.org
--- Comment #27 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #26)
> If you create a new thread of execution then you'll get a non-weak reference
> to pthread_create, which should cause libpthread.so to be linked even with
> -Wl,--as-needed (and for static linking it will work if libpthread.a has a
> single .o with all symbols).
>
> If you don't actually have multiple threads in your program, then things
> like condition_variable and once_flag can end up using the stubs in
> libc.so.6 which are no-ops. But since you don't have multiple threads, it's
> probably not a major problem.
For call_once, it throws an exception whether there are other threads or not,
it isn't a no-op.
(as you might guess, this code is in a library, I don't control if threads are
used elsewhere)
> Most uses of std::once_flag would be better
> done with a local static variable anyway (the exception being non-static
> data members of classes).
I build trees with a once_flag in each node, there is no way I can do that with
static variables.
> With glibc 2.34 the problem goes away, so I'm not sure it's worth investing
> much effort in libstdc++ trying to work around the problems with weak
> symbols.
Ok. I just wanted to advertise that the issue is not limited to static linking.
(too bad you had to revert the new call_once implementation)
