[Bug libstdc++/58909] New: C++11's condition variables fail with static linkin

[Bug libstdc++/58909] New: C++11's condition variables fail with static linkin

[joel at clambassador dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909

            Bug ID: 58909
           Summary: C++11's condition variables fail with static linkin
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: joel at clambassador dot com

The program: 

#include <condition_variable>
int main () { std::condition_variable a; }

statically compiled as either:
g++ --std=c++0x -static -pthread aa.cc -lpthread
clang++ --std=c++11 -static -pthread aa.cc -lpthread

segfaults at the destructor's implicit call to pthread_cond_destroy(). Other
uses of std::condition_variable also fail. nm shows that pthread_cond_*
functions are only 'w', while programs that use other aspects of c++ threading,
such as mutexes, will have 'W' pthread_mutex_* and corresponding "T"
__pthread_mutex_* available.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If this is NPTL, then the fix is to either avoid using -static (lots of reasons
not to do it), or -Wl,--whole-archive -lpthread -Wl,--no-whole-archive
instead of -lpthread (in some distributions like Fedora the latter is
unnecessary, as -lpthread contains a single large *.o file for these reasons).

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tomas.ukkonen at iki dot fi

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 66071 has been marked as a duplicate of this bug. ***

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |g.bonacci at libero dot it

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 98098 has been marked as a duplicate of this bug. ***

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[ksaunders at nowsecure dot com]

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

Keegan Saunders <ksaunders at nowsecure dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ksaunders at nowsecure dot com

--- Comment #12 from Keegan Saunders <ksaunders at nowsecure dot com> ---
This behaviour does not occur with clang when statically linking libc++. It is,
however, still an issue on clang and gcc when using libstdc++.

It is still possible to reproduce this issue with:

clang version 11.0.0 (Fedora 11.0.0-2.fc33)

and

g++ (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)

As libc++ links against glibc, this appears to be strictly an issue with
libstdc++ rather than glibc.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Maybe libc++ doesn't bother with supporting not linking against -lpthread.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #13)
> Maybe libc++ doesn't bother with supporting not linking against -lpthread.

libc++ is linked to libpthread.so unconditionally.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And the static libc++.a doesn't use weak symbols, so you need to link to
libpthread youself, and the necessary symbols get pulled in correctly.

The problem for libstdc++.a is that the weak symbols do not cause the
libpthread.a symbols to get linked into the binary.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Are those weak refs from libstdc++.a objects or from the user *.o files?
If the former, perhaps we could declare some libstdc++ APIs (related to
threading) as requiring linking of -lpthread and made them non-weak in
libstdc++.a.
I don't really see how can one reproduce this on Fedora/RHEL/CentOS where
libpthread.a
contains a single libpthread.o and therefore it is either you link no thread
support at all, or link it completely.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #16)
> Are those weak refs from libstdc++.a objects or from the user *.o files?

>From libstdc++.a

> If the former, perhaps we could declare some libstdc++ APIs (related to
> threading) as requiring linking of -lpthread and made them non-weak in
> libstdc++.a.

Yes, I think we should just use the non-weak pthread_xxx symbols directly when
!defined(_GLIBCXX_SHARED) and rely on those sections from libstdc++.a not being
used unless they're needed.

> I don't really see how can one reproduce this on Fedora/RHEL/CentOS where
> libpthread.a
> contains a single libpthread.o and therefore it is either you link no thread
> support at all, or link it completely.

The example in comment 0 fails on Fedora. Nothing in libstdc++.a causes
anything from libpthread.o to be used.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #17)
> (In reply to Jakub Jelinek from comment #16)
> The example in comment 0 fails on Fedora. Nothing in libstdc++.a causes
> anything from libpthread.o to be used.

However, any real program that uses std::condition_variable is likely to also
use std::thread, and that will cause a dependency on symbols in libpthread.o

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Is that because some functions are also in libc.a and not just in libpthread.a?

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I don't think so. The linker just doesn't resolve the undefined weak symbol for
pthread_cond_destroy is left equal to zero, and so there's a segfault when it
gets called.

$ g++ cv.C -static -g -Wl,--trace-symbol=pthread_cond_destroy -pthread
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/10/libstdc++.a(condition_variable.o):
reference to pthread_cond_destroy


IIUC it's not finding the definition in libc.a, or any definition at all.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So how does that work for dynamic linking when -lpthread is not linked in?
Does it crash too?

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[redi at gcc dot gnu.org]

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

--- Comment #22 from Jonathan Wakely <redi at gcc dot gnu.org> ---
In that case it finds the no-op symbol in libc.so.6 and doesn't crash.

$ g++ cv.C   -g -Wl,--trace-symbol=pthread_cond_destroy 
/usr/bin/ld: /lib64/libc.so.6: definition of pthread_cond_destroy


This fixes the static linking case:

--- a/libstdc++-v3/src/c++11/condition_variable.cc
+++ b/libstdc++-v3/src/c++11/condition_variable.cc
@@ -31,9 +31,19 @@ namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION

-  condition_variable::condition_variable() noexcept = default;
+  condition_variable::condition_variable() noexcept
+  {
+#if defined __GLIBC__ && ! defined _GLIBCXX_SHARED
+    asm("extern pthread_cond_init");
+#endif
+  }

-  condition_variable::~condition_variable() noexcept = default;
+  condition_variable::~condition_variable() noexcept
+  {
+#if defined __GLIBC__ && ! defined _GLIBCXX_SHARED
+    asm("extern pthread_cond_destroy");
+#endif
+  }

   void
   condition_variable::wait(unique_lock<mutex>& __lock) noexcept

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Unaware of extern directive in gas.
I'd think (but it would need to be surrounded by configury checks) that
something like:
.section .gnu.need.pthread_cond, "e"
.8byte pthread_cond_init
...
.previous
where you'd list all the symbols you want to force in should work though, and
wouldn't actually waste .data or .rodata.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Actually asm (".global pthread_cond_init"); (etc.) is probably better, doesn't
need relocations, just adds the symbol to the symtab as non-weak.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-01-28
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|redi at gcc dot gnu.org            |unassigned at gcc dot gnu.org
             Status|ASSIGNED                    |NEW

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[glisse at gcc dot gnu.org]

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

--- Comment #25 from Marc Glisse <glisse at gcc dot gnu.org> ---
Note that this also affects dynamic linking with -Wl,--as-needed (which some
platforms use by default).

#include <mutex>
int main(){
  std::once_flag o;
  std::call_once(o, [](){});
}

$ g++ b.cc -lpthread && ldd ./a.out            
        linux-vdso.so.1 (0x00007ffca7b60000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f9c809ac000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9c807e7000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9c806a3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f9c80bd4000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f9c80689000)

No libpthread there :-(

(using -pthread instead of -lpthread works, but some build systems like cmake
use -lpthread by default)

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely <redi at gcc dot gnu.org> ---
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. 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).

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.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[glisse at gcc dot gnu.org]

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)

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilg at livius dot net

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 115421 has been marked as a duplicate of this bug. ***