https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
--- Comment #5 from Iain Sandoe ---
Sorry, my intended design was not stated very clearly.
1. IIUC, the objective is to have only one instance of these symbols in the
dynamically-linked program.
2. One way to ensure that is to make it a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
--- Comment #3 from Iain Sandoe ---
(In reply to Florian Weimer from comment #2)
> Weak symbols have no meaning for ELF DSOs, so this wouldn't work for
> libgcc_s on ELF targets. Instead we automatically link against dynamic
> libgcc_s if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
--- Comment #2 from Florian Weimer ---
Weak symbols have no meaning for ELF DSOs, so this wouldn't work for libgcc_s
on ELF targets. Instead we automatically link against dynamic libgcc_s if
certain symbols not in libgcc.a are referenced.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
--- Comment #1 from Iain Sandoe ---
this seems a somewhat similar dilemma to the emulated TLS case.
Perhaps:
provide a weak definition of these in a CRT (which is used for -static-libgcc)
and weaken the defs in libgcc_s so that mixed
