public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin
@ 2013-10-29 2:43 joel at clambassador dot com
2013-10-29 9:53 ` [Bug libstdc++/58909] C++11's condition variables fail with static linking jakub at gcc dot gnu.org
` (21 more replies)
0 siblings, 22 replies; 23+ messages in thread
From: joel at clambassador dot com @ 2013-10-29 2:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
@ 2013-10-29 9:53 ` jakub at gcc dot gnu.org
2015-05-08 15:13 ` redi at gcc dot gnu.org
` (20 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-10-29 9:53 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
2013-10-29 9:53 ` [Bug libstdc++/58909] C++11's condition variables fail with static linking jakub at gcc dot gnu.org
@ 2015-05-08 15:13 ` redi at gcc dot gnu.org
2020-12-02 16:36 ` redi at gcc dot gnu.org
` (19 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2015-05-08 15:13 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
2013-10-29 9:53 ` [Bug libstdc++/58909] C++11's condition variables fail with static linking jakub at gcc dot gnu.org
2015-05-08 15:13 ` redi at gcc dot gnu.org
@ 2020-12-02 16:36 ` redi at gcc dot gnu.org
2021-01-28 16:48 ` ksaunders at nowsecure dot com
` (18 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2020-12-02 16:36 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (2 preceding siblings ...)
2020-12-02 16:36 ` redi at gcc dot gnu.org
@ 2021-01-28 16:48 ` ksaunders at nowsecure dot com
2021-01-28 16:58 ` jakub at gcc dot gnu.org
` (17 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: ksaunders at nowsecure dot com @ 2021-01-28 16:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (3 preceding siblings ...)
2021-01-28 16:48 ` ksaunders at nowsecure dot com
@ 2021-01-28 16:58 ` jakub at gcc dot gnu.org
2021-01-28 17:32 ` redi at gcc dot gnu.org
` (16 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-28 16:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (4 preceding siblings ...)
2021-01-28 16:58 ` jakub at gcc dot gnu.org
@ 2021-01-28 17:32 ` redi at gcc dot gnu.org
2021-01-28 17:42 ` redi at gcc dot gnu.org
` (15 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-01-28 17:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (5 preceding siblings ...)
2021-01-28 17:32 ` redi at gcc dot gnu.org
@ 2021-01-28 17:42 ` redi at gcc dot gnu.org
2021-01-28 17:49 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-01-28 17:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (6 preceding siblings ...)
2021-01-28 17:42 ` redi at gcc dot gnu.org
@ 2021-01-28 17:49 ` jakub at gcc dot gnu.org
2021-01-28 18:01 ` redi at gcc dot gnu.org
` (13 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-28 17:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (7 preceding siblings ...)
2021-01-28 17:49 ` jakub at gcc dot gnu.org
@ 2021-01-28 18:01 ` redi at gcc dot gnu.org
2021-01-28 18:07 ` redi at gcc dot gnu.org
` (12 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-01-28 18:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (8 preceding siblings ...)
2021-01-28 18:01 ` redi at gcc dot gnu.org
@ 2021-01-28 18:07 ` redi at gcc dot gnu.org
2021-01-28 18:17 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-01-28 18:07 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (9 preceding siblings ...)
2021-01-28 18:07 ` redi at gcc dot gnu.org
@ 2021-01-28 18:17 ` jakub at gcc dot gnu.org
2021-01-28 18:39 ` redi at gcc dot gnu.org
` (10 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-28 18:17 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (10 preceding siblings ...)
2021-01-28 18:17 ` jakub at gcc dot gnu.org
@ 2021-01-28 18:39 ` redi at gcc dot gnu.org
2021-01-28 18:48 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-01-28 18:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (11 preceding siblings ...)
2021-01-28 18:39 ` redi at gcc dot gnu.org
@ 2021-01-28 18:48 ` jakub at gcc dot gnu.org
2021-01-28 19:00 ` redi at gcc dot gnu.org
` (8 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-28 18:48 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (12 preceding siblings ...)
2021-01-28 18:48 ` jakub at gcc dot gnu.org
@ 2021-01-28 19:00 ` redi at gcc dot gnu.org
2021-01-28 19:12 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-01-28 19:00 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (13 preceding siblings ...)
2021-01-28 19:00 ` redi at gcc dot gnu.org
@ 2021-01-28 19:12 ` jakub at gcc dot gnu.org
2021-01-28 19:24 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-28 19:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (14 preceding siblings ...)
2021-01-28 19:12 ` jakub at gcc dot gnu.org
@ 2021-01-28 19:24 ` jakub at gcc dot gnu.org
2021-01-28 20:41 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-28 19:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (15 preceding siblings ...)
2021-01-28 19:24 ` jakub at gcc dot gnu.org
@ 2021-01-28 20:41 ` redi at gcc dot gnu.org
2021-04-19 10:40 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-01-28 20:41 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (16 preceding siblings ...)
2021-01-28 20:41 ` redi at gcc dot gnu.org
@ 2021-04-19 10:40 ` redi at gcc dot gnu.org
2021-07-22 8:10 ` glisse at gcc dot gnu.org
` (3 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-04-19 10:40 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (17 preceding siblings ...)
2021-04-19 10:40 ` redi at gcc dot gnu.org
@ 2021-07-22 8:10 ` glisse at gcc dot gnu.org
2021-07-22 8:55 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: glisse at gcc dot gnu.org @ 2021-07-22 8:10 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (18 preceding siblings ...)
2021-07-22 8:10 ` glisse at gcc dot gnu.org
@ 2021-07-22 8:55 ` redi at gcc dot gnu.org
2021-07-22 10:45 ` glisse at gcc dot gnu.org
2024-06-11 9:39 ` rguenth at gcc dot gnu.org
21 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2021-07-22 8:55 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (19 preceding siblings ...)
2021-07-22 8:55 ` redi at gcc dot gnu.org
@ 2021-07-22 10:45 ` glisse at gcc dot gnu.org
2024-06-11 9:39 ` rguenth at gcc dot gnu.org
21 siblings, 0 replies; 23+ messages in thread
From: glisse at gcc dot gnu.org @ 2021-07-22 10:45 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/58909] C++11's condition variables fail with static linking
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
` (20 preceding siblings ...)
2021-07-22 10:45 ` glisse at gcc dot gnu.org
@ 2024-06-11 9:39 ` rguenth at gcc dot gnu.org
21 siblings, 0 replies; 23+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-06-11 9:39 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2024-06-11 9:39 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-29 2:43 [Bug libstdc++/58909] New: C++11's condition variables fail with static linkin joel at clambassador dot com
2013-10-29 9:53 ` [Bug libstdc++/58909] C++11's condition variables fail with static linking jakub at gcc dot gnu.org
2015-05-08 15:13 ` redi at gcc dot gnu.org
2020-12-02 16:36 ` redi at gcc dot gnu.org
2021-01-28 16:48 ` ksaunders at nowsecure dot com
2021-01-28 16:58 ` jakub at gcc dot gnu.org
2021-01-28 17:32 ` redi at gcc dot gnu.org
2021-01-28 17:42 ` redi at gcc dot gnu.org
2021-01-28 17:49 ` jakub at gcc dot gnu.org
2021-01-28 18:01 ` redi at gcc dot gnu.org
2021-01-28 18:07 ` redi at gcc dot gnu.org
2021-01-28 18:17 ` jakub at gcc dot gnu.org
2021-01-28 18:39 ` redi at gcc dot gnu.org
2021-01-28 18:48 ` jakub at gcc dot gnu.org
2021-01-28 19:00 ` redi at gcc dot gnu.org
2021-01-28 19:12 ` jakub at gcc dot gnu.org
2021-01-28 19:24 ` jakub at gcc dot gnu.org
2021-01-28 20:41 ` redi at gcc dot gnu.org
2021-04-19 10:40 ` redi at gcc dot gnu.org
2021-07-22 8:10 ` glisse at gcc dot gnu.org
2021-07-22 8:55 ` redi at gcc dot gnu.org
2021-07-22 10:45 ` glisse at gcc dot gnu.org
2024-06-11 9:39 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).