https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #26 from Jonathan Wakely ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #25 from Marc Glisse ---
Note that this also affects dynamic linking with -Wl,--as-needed (which some
platforms use by default).
#include
int main(){
std::once_flag o;
std::call_once(o, [](){});
}
$ g++ b.cc -lpthread && ldd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-01-28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #24 from Jakub Jelinek ---
Actually asm (".global pthread_cond_init"); (etc.) is probably better, doesn't
need relocations, just adds the symbol to the symtab as non-weak.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #23 from Jakub Jelinek ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #22 from Jonathan Wakely ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #21 from Jakub Jelinek ---
So how does that work for dynamic linking when -lpthread is not linked in?
Does it crash too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #20 from Jonathan Wakely ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #19 from Jakub Jelinek ---
Is that because some functions are also in libc.a and not just in libpthread.a?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #18 from Jonathan Wakely ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #17 from Jonathan Wakely ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #16 from Jakub Jelinek ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #15 from Jonathan Wakely ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #14 from Jonathan Wakely ---
(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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #13 from Jakub Jelinek ---
Maybe libc++ doesn't bother with supporting not linking against -lpthread.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Keegan Saunders changed:
What|Removed |Added
CC||ksaunders at nowsecure dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Jonathan Wakely changed:
What|Removed |Added
CC||g.bonacci at libero dot it
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
abbycin changed:
What|Removed |Added
CC||abbytsing at hotmail dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
joel at clambassador dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #8 from Jonathan Wakely ---
Well Roland's fix doesn't work, and his claims about libstdc++ problems are
based on ancient history, so I don't find his arguments very persuasive.
I'm happy to document the requirements in the libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #7 from Brooks Moses ---
Right, understood, but Roland seemed pretty insistent in the discussion on bug
57740 that this was a libstdc++ bug, not a glibc bug. Your contention is that
this is invalid because he's wrong about that, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
--- Comment #6 from Jakub Jelinek ---
INVALID means it is not a gcc bug, glibc has a separate bugzilla.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Brooks Moses changed:
What|Removed |Added
CC||brooks at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Andrew Pinski changed:
What|Removed |Added
CC||roland at gnu dot org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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
29 matches
Mail list logo
