https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #14 from Richard Biener ---
Ping.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #13 from Jakub Jelinek ---
(In reply to Richard Biener from comment #12)
> then shouldn't the
> solution be that programs using streams and compiled with GCC 13 require
> a symbol with a version newer than 6.0.30 (or even not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #12 from Richard Biener ---
I wonder why this bug is relevant at all, but even if, then shouldn't the
solution be that programs using streams and compiled with GCC 13 require
a symbol with a version newer than 6.0.30 (or even not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #10 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #8)
> Unfortunately we build libstdc++ objects just once because even libstdc++.a
> contains -fPIC code. So not sure how to arrange it to be libstdc++.so only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #9 from Richard Biener ---
(In reply to Florian Weimer from comment #6)
> (In reply to Jonathan Wakely from comment #2)
> > --- a/libstdc++-v3/src/c++98/globals_io.cc
> > +++ b/libstdc++-v3/src/c++98/globals_io.cc
> > @@ -43,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #8 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #7)
> I think they're exported correctly with both versions:
>
> $ nm -D --defined-only src/.libs/libstdc++.so.6.0.31 | grep '_ZSt[345]c'
> 0025d7a0 B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #7 from Jonathan Wakely ---
I think they're exported correctly with both versions:
$ nm -D --defined-only src/.libs/libstdc++.so.6.0.31 | grep '_ZSt[345]c'
0025d7a0 B _ZSt3cin@@GLIBCXX_3.4
0025d7a0 B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #6 from Florian Weimer ---
(In reply to Jonathan Wakely from comment #2)
> --- a/libstdc++-v3/src/c++98/globals_io.cc
> +++ b/libstdc++-v3/src/c++98/globals_io.cc
> @@ -43,6 +43,12 @@
> // In macro form:
> //
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #5 from Jakub Jelinek ---
Even for the partial Linux solution, you need to make sure that those variables
are exported as both _ZSt5wcout@GLIBCXX_3.4 and _ZSt5wcout@@GLIBCXX_3.4.31
(same address i.e. aliases).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #4 from Jonathan Wakely ---
The patch above means that a program using cout (or any of the standard
streams) gets:
00404040 B _ZSt4cout@GLIBCXX_3.4.31
instead of:
00404040 B _ZSt4cout@GLIBCXX_3.4
And then it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #3 from Jakub Jelinek ---
You're right, it can be done just on the library side.
Though, only for GNU symbol versioning, I think the Solaris one doesn't allow
having one symbol with multiple symbol versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #2 from Jonathan Wakely ---
--- a/libstdc++-v3/src/c++98/globals_io.cc
+++ b/libstdc++-v3/src/c++98/globals_io.cc
@@ -43,6 +43,12 @@
// In macro form:
// _GLIBCXX_ASM_SYMVER(currentname, oldname, GLIBCXX_3.2)
+#if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
15 matches
Mail list logo
