[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #33 from Jakub Jelinek --- Should be fixed now (for Linux targets) for 13.2/14.1 and later.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #32 from CVS Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:9c9061e0418ded473672069aac43b25f6fd491b8
commit r13-7287-g9c9061e0418ded473672069aac43b25f6fd491b8
Author: Jakub Jelinek
Date: Fri Apr 28 10:49:40 2023 +0200
libstdc++: Another attempt to ensure g++ 13+ compiled programs enforce gcc
13.2+ libstdc++.so.6 [PR108969]
GCC used to emit an instance of an empty ios_base::Init class in
every TU which included to ensure it is std::cout etc.
is initialized, but thanks to Patrick work on some targets (which have
init_priority attribute support) it is now initialized only inside of
libstdc++.so.6/libstdc++.a.
This causes a problem if people do something that has never been supported,
try to run GCC 13 compiled C++ code against GCC 12 or earlier
libstdc++.so.6 - std::cout etc. are then never initialized because code
including expects the library to initialize it and the library
expects code including to do that.
The following patch is second attempt to make this work cheaply as the
earlier attempt of aliasing the std::cout etc. symbols with another symbol
version didn't work out due to copy relocation breaking the aliases appart.
The patch forces just a _ZSt21ios_base_library_initv undefined symbol
into all *.o files which include and while there is no runtime
relocation against that, it seems to enforce the right version of
libstdc++.so.6. /home/jakub/src/gcc/obj08i/usr/local/ is the install
directory of trunk patched with this patch, /home/jakub/src/gcc/obj06/
is builddir of trunk without this patch, system g++ is GCC 12.1.1.
$ cat /tmp/hw.C
#include
int
main ()
{
std::cout << "Hello, world!" << std::endl;
}
$ cd /home/jakub/src/gcc/obj08i/usr/local/bin
$ ./g++ -o /tmp/hw /tmp/hw.C
$ readelf -Wa /tmp/hw 2>/dev/null | grep initv
4: 0 FUNCGLOBAL DEFAULT UND
_ZSt21ios_base_library_initv@GLIBCXX_3.4.32 (4)
71: 0 FUNCGLOBAL DEFAULT UND
_ZSt21ios_base_library_initv@GLIBCXX_3.4.32
$ /tmp/hw
/tmp/hw: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.32' not found
(required by /tmp/hw)
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw
Hello, world!
$
LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/
/tmp/hw
/tmp/hw:
/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6:
version `GLIBCXX_3.4.32' not found (required by /tmp/hw)
$ g++ -o /tmp/hw /tmp/hw.C
$ /tmp/hw
Hello, world!
$
LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/
/tmp/hw
Hello, world!
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw
Hello, world!
On sparc-sun-solaris2.11 one I've actually checked a version which had
defined(_GLIBCXX_SYMVER_SUN) next to defined(_GLIBCXX_SYMVER_GNU), but
init_priority attribute doesn't seem to be supported there and so I
couldn't
actually test how this works there. Using gas and Sun ld, Rainer, does one
need to use gas + gld for init_priority or something else?
2023-04-28 Jakub Jelinek
PR libstdc++/108969
* config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Export
_ZSt21ios_base_library_initv.
* testsuite/util/testsuite_abi.cc (check_version): Add
GLIBCXX_3.4.32
symver and make it the latestp.
* src/c++98/ios_init.cc (ios_base_library_init): New alias.
* acinclude.m4 (libtool_VERSION): Change to 6:32:0.
* include/std/iostream: If init_priority attribute is supported
and _GLIBCXX_SYMVER_GNU, force undefined
_ZSt21ios_base_library_initv
symbol into the object.
* configure: Regenerated.
(cherry picked from commit 9a41d2cdbcd2af77a3a91a840a3a13f0eb39971b)
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #31 from Romain Geissler --- Ok thanks for confirming. I was about to ask for a deployment one of our gcc-based toolchain in production containing the current gcc 13.1.1, I will wait a bit that this patch lands in the gcc 13 branch then. And in the future I will pay more attention to newly added symbols/gnu versions in minor version of libstdc++ why deploying new toolchains then ;)
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #30 from Jonathan Wakely --- (In reply to Romain Geissler from comment #28) > In other words, in general, is there any guarantee that something built > using gcc N.X.0 can be run with the runtime of gcc N.Y.0 for X > Y ? No. There have been several times where that was not possible: https://gcc.gnu.org/onlinedocs/gcc-13.1.0/libstdc++/manual/manual/abi.html#abi.versioning.history e.g. 7.2.0 had new symbols not present in 7.1.0, and 9.2.0 and 9.3.0 both introduced new symbols compared to the previous release.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #29 from Romain Geissler --- Typo: If yes, given that you also maintain the gcc package in fedora 38 (https://src.fedoraproject.org/rpms/gcc/commits/f38), does it mean that something built in some future up to date Fedora 38 won't run on an old "unpatched"/"not up to date" fedora 38 ?
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #28 from Romain Geissler --- Hi, Sorry to jump here, but I wish to clarify something. If I understood the commit message/diff correctly, I expect that this commit will eventually land in the gcc 13 branch, not just in master, right ? So let's imagine gcc 13.2.0 is released with this, it will mean that a binary (including ) built with gcc 13.2.0 won't be runnable with the runtime of gcc 13.1.0 ? If yes, given that you also maintain the gcc package in fedora 38 (https://src.fedoraproject.org/rpms/gcc/commits/f38), does it mean that something build in some future up to date Fedora 38 won't build on an old "unpatched" fedora 38 ? In other words, in general, is there any guarantee that something built using gcc N.X.0 can be run with the runtime of gcc N.Y.0 for X > Y ? (I am not speaking about mixing gcc 13 with gcc 12, but point releases of gcc 13). Cheers, Romain
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #27 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9a41d2cdbcd2af77a3a91a840a3a13f0eb39971b
commit r14-321-g9a41d2cdbcd2af77a3a91a840a3a13f0eb39971b
Author: Jakub Jelinek
Date: Fri Apr 28 10:49:40 2023 +0200
libstdc++: Another attempt to ensure g++ 13+ compiled programs enforce gcc
13.2+ libstdc++.so.6 [PR108969]
GCC used to emit an instance of an empty ios_base::Init class in
every TU which included to ensure it is std::cout etc.
is initialized, but thanks to Patrick work on some targets (which have
init_priority attribute support) it is now initialized only inside of
libstdc++.so.6/libstdc++.a.
This causes a problem if people do something that has never been supported,
try to run GCC 13 compiled C++ code against GCC 12 or earlier
libstdc++.so.6 - std::cout etc. are then never initialized because code
including expects the library to initialize it and the library
expects code including to do that.
The following patch is second attempt to make this work cheaply as the
earlier attempt of aliasing the std::cout etc. symbols with another symbol
version didn't work out due to copy relocation breaking the aliases appart.
The patch forces just a _ZSt21ios_base_library_initv undefined symbol
into all *.o files which include and while there is no runtime
relocation against that, it seems to enforce the right version of
libstdc++.so.6. /home/jakub/src/gcc/obj08i/usr/local/ is the install
directory of trunk patched with this patch, /home/jakub/src/gcc/obj06/
is builddir of trunk without this patch, system g++ is GCC 12.1.1.
$ cat /tmp/hw.C
#include
int
main ()
{
std::cout << "Hello, world!" << std::endl;
}
$ cd /home/jakub/src/gcc/obj08i/usr/local/bin
$ ./g++ -o /tmp/hw /tmp/hw.C
$ readelf -Wa /tmp/hw 2>/dev/null | grep initv
4: 0 FUNCGLOBAL DEFAULT UND
_ZSt21ios_base_library_initv@GLIBCXX_3.4.32 (4)
71: 0 FUNCGLOBAL DEFAULT UND
_ZSt21ios_base_library_initv@GLIBCXX_3.4.32
$ /tmp/hw
/tmp/hw: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.32' not found
(required by /tmp/hw)
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw
Hello, world!
$
LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/
/tmp/hw
/tmp/hw:
/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6:
version `GLIBCXX_3.4.32' not found (required by /tmp/hw)
$ g++ -o /tmp/hw /tmp/hw.C
$ /tmp/hw
Hello, world!
$
LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/
/tmp/hw
Hello, world!
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw
Hello, world!
On sparc-sun-solaris2.11 one I've actually checked a version which had
defined(_GLIBCXX_SYMVER_SUN) next to defined(_GLIBCXX_SYMVER_GNU), but
init_priority attribute doesn't seem to be supported there and so I
couldn't
actually test how this works there. Using gas and Sun ld, Rainer, does one
need to use gas + gld for init_priority or something else?
2023-04-28 Jakub Jelinek
PR libstdc++/108969
* config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Export
_ZSt21ios_base_library_initv.
* testsuite/util/testsuite_abi.cc (check_version): Add
GLIBCXX_3.4.32
symver and make it the latestp.
* src/c++98/ios_init.cc (ios_base_library_init): New alias.
* acinclude.m4 (libtool_VERSION): Change to 6:32:0.
* include/std/iostream: If init_priority attribute is supported
and _GLIBCXX_SYMVER_GNU, force undefined
_ZSt21ios_base_library_initv
symbol into the object.
* configure: Regenerated.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 Xi Ruoyao changed: What|Removed |Added CC||bremende55 at gmail dot com --- Comment #26 from Xi Ruoyao --- *** Bug 109633 has been marked as a duplicate of this bug. ***
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 Richard Biener changed: What|Removed |Added Target Milestone|13.0|13.2 --- Comment #25 from Richard Biener --- GCC 13.1 is being released, retargeting bugs to GCC 13.2.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #24 from Jakub Jelinek ---
You're right. libstdc++.so.6 would then initialize just the old symver copy
and not the new one, which could be used by newer shared libraries.
So that leaves the asm (".globl _Zwhatever"); in the header file.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #23 from Florian Weimer --- (In reply to Jakub Jelinek from comment #20) > So, when the @@GLIBCXX_3.4.31 alias is weak, at least the F36 linker puts > into the binary not just one but both symbols and so the aliasing isn't > broken. I'm not sure this is sufficient because old programs will only have the @GLIBCXX_3.4 reference and still break the aliases if copy relocations are involved. The internal libstdc++ things we could perhaps resolve, but even with that, it will only work if everything in the executable either uses the old version, or the new version. Mixed-mode operation still won't work because of the separation of the aliases.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
--- Comment #22 from Jakub Jelinek ---
extern int cinalias __attribute__((__symver__ ("_ZSt4cin@GLIBCXX_3.4")));
void foo ()
{
cinalias++;
}
doesn't work to refer to older symver, but
extern int cinalias;
asm (".symver cinalias, _ZSt4cin@GLIBCXX_3.4");
void foo ()
{
cinalias++;
}
does. Of course, needs testing with old binutils and the like.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #21 from Sam James --- The commits got reverted in r14-76-ga6e4b81b12e57b and r14-77-gfac24d43e68838 after marxin reported a segfault with mold in #gcc and fweimer reported an issue with cmake at https://bugzilla.redhat.com/show_bug.cgi?id=2187768#c4.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #20 from Jakub Jelinek ---
So,
( for i in 7.c 7.ver 7a.c 7a.ver 8.c 7.h; do echo $i; cat /tmp/$i; done; gcc
-shared -fpic -Wl,--version-script=/tmp/7.ver /tmp/7.c -o /tmp/7.so; gcc -I
/tmp/ -o /tmp/8 /tmp/8.c /tmp/7.so; /tmp/8; echo $?; gcc -shared -fpic
-Wl,--version-script=/tmp/7a.ver /tmp/7a.c -o /tmp/7.so; /tmp/8; echo $? )
7.c
void
_Zwhatever (void)
{
}
void
foo (void)
{
}
7.ver
GLIBCXX_3.4.31 {
global: foo;
local: *;
};
GLIBCXX_3.4.32 {
global: _Zwhatever;
} GLIBCXX_3.4.31;
7a.c
void
foo (void)
{
}
7a.ver
GLIBCXX_3.4.31 {
global: foo;
local: *;
};
8.c
#include "7.h"
int
main ()
{
}
7.h
asm (".globl _Zwhatever");
0
/tmp/8: /tmp/7.so: version `GLIBCXX_3.4.32' not found (required by /tmp/8)
1
is one proof-of-concept on what we could do.
Another one is
/tmp/4.C
namespace std {
# define _GLIBCXX_IO_GLOBAL(type, X, N) namespace __io { type X
__attribute__((__symver__ ("_ZSt" #N #X "@GLIBCXX_3.4"))); } \
extern type X##alias __attribute__((__weak__, __alias__ ("_ZNSt4__io" #N #X
"E"), __symver__ ("_ZSt" #N #X "@@GLIBCXX_3.4.31")));
_GLIBCXX_IO_GLOBAL(int, cin, 3)
_GLIBCXX_IO_GLOBAL(int, cout, 4)
_GLIBCXX_IO_GLOBAL(int, cerr, 4)
_GLIBCXX_IO_GLOBAL(int, clog, 4)
}
/tmp/4.c
extern int _ZSt4cerr;
int
main ()
{
_ZSt4cerr++;
}
/tmp/4.ver
GLIBCXX_3.4 {
global:
_ZSt3cin;
_ZSt4cerr;
_ZSt4cout;
_ZSt4clog;
local: *;
};
GLIBCXX_3.4.31 {
global:
_ZSt3cin;
_ZSt4cerr;
_ZSt4cout;
_ZSt4clog;
} GLIBCXX_3.4;
gcc -shared -o /tmp/4.so /tmp/4.C -fpic -Wl,--version-script=/tmp/4.ver
gcc -o /tmp/4 /tmp/4.c /tmp/4.so
eadelf -Wa /tmp/4 2>&1 | grep cerr
0040401c 00040005 R_X86_64_COPY 0040401c
_ZSt4cerr@GLIBCXX_3.4 + 0
3: 0040401c 4 OBJECT WEAK DEFAULT 23
_ZSt4cerr@GLIBCXX_3.4.31 (3)
4: 0040401c 4 OBJECT GLOBAL DEFAULT 23
_ZSt4cerr@GLIBCXX_3.4 (4)
58: 0040401c 4 OBJECT WEAK DEFAULT 23
_ZSt4cerr@GLIBCXX_3.4.31
59: 0040401c 4 OBJECT GLOBAL DEFAULT 23
_ZSt4cerr@GLIBCXX_3.4
So, when the @@GLIBCXX_3.4.31 alias is weak, at least the F36 linker puts into
the binary not just one but both symbols and so the aliasing isn't broken.
We'd need to also arrange for ios_init.o to refer to _ZSt4cerr@GLIBCXX_3.4
rather than _ZSt4cerr, because binaries built against older libstdc++ will have
just _ZSt4cerr@GLIBCXX_3.4 symbol on the copy relocation.
Or combination of both, do the former on Solaris and the latter on Linux. To
be tested with older linkers/assemblers, non-glibc dynamic linkers and the
like.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #18 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6067ae4557a3a7e5b08359e78a29b8a9d5dfedce commit r14-46-g6067ae4557a3a7e5b08359e78a29b8a9d5dfedce Author: Jonathan Wakely Date: Tue Apr 18 17:22:40 2023 +0100 libstdc++: Fix preprocessor condition in linker script [PR108969] The linker script is preprocessed with $(top_builddir)/config.h not the include/$target/bits/c++config.h version, which means that configure macros do not have the _GLIBCXX_ prefix yet. The _GLIBCXX_SYMVER_GNU and _GLIBCXX_SHARED checks are redundant, because the gnu.ver file is only used for _GLIBCXX_SYMVER_GNU and the linker script is only used for the shared library. Remove those. libstdc++-v3/ChangeLog: PR libstdc++/108969 * config/abi/pre/gnu.ver: Fix preprocessor condition.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #19 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ed933888e680384e1e7af361b20dd484ad424f7d commit r13-7218-ged933888e680384e1e7af361b20dd484ad424f7d Author: Jonathan Wakely Date: Tue Apr 18 17:22:40 2023 +0100 libstdc++: Fix preprocessor condition in linker script [PR108969] The linker script is preprocessed with $(top_builddir)/config.h not the include/$target/bits/c++config.h version, which means that configure macros do not have the _GLIBCXX_ prefix yet. The _GLIBCXX_SYMVER_GNU and _GLIBCXX_SHARED checks are redundant, because the gnu.ver file is only used for _GLIBCXX_SYMVER_GNU and the linker script is only used for the shared library. Remove those. libstdc++-v3/ChangeLog: PR libstdc++/108969 * config/abi/pre/gnu.ver: Fix preprocessor condition. (cherry picked from commit 6067ae4557a3a7e5b08359e78a29b8a9d5dfedce)
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from Jonathan Wakely --- Fixed for 13.1
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #16 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:762be0646bf96761ce68a9e06ab60c453e0963d0 commit r13-7217-g762be0646bf96761ce68a9e06ab60c453e0963d0 Author: Jonathan Wakely Date: Tue Apr 18 14:37:38 2023 +0100 libstdc++: Export global iostreams with GLIBCXX_3.4.31 symver [PR108969] Since GCC 13 the global iostream objects are only initialized once in libstdc++, and not by a std::ios::Init object in every translation unit that includes . To avoid using uninitialized streams defined in an older libstdc++.so, translation units using the global iostreams should depend on the GLIBCXX_3.4.31 symver. Define std::cin as std::__io::cin and then export it as std::cin@@GLIBCXX_3.4.31 so that references to std::cin bind to the new symver. Also export it as @GLIBCXX_3.4 for backwards compatibility libstdc++-v3/ChangeLog: PR libstdc++/108969 * src/Makefile.am: Move globals_io.cc to here. * src/Makefile.in: Regenerate. * src/c++98/Makefile.am: Remove globals_io.cc from here. * src/c++98/Makefile.in: Regenerate. * src/c++98/globals_io.cc [_GLIBCXX_SYMVER_GNU] (cin): Adjust symbol name and then export with GLIBCXX_3.4.31 symver. (cout, cerr, clog, wcin, wcout, wcerr, wclog): Likewise. * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Regenerate. * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/pre/gnu.ver: Add iostream objects to new symver.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #15 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b7c54e3f48086c29179f7765a35c381de5109a0a commit r14-43-gb7c54e3f48086c29179f7765a35c381de5109a0a Author: Jonathan Wakely Date: Tue Apr 18 14:37:38 2023 +0100 libstdc++: Export global iostreams with GLIBCXX_3.4.31 symver [PR108969] Since GCC 13 the global iostream objects are only initialized once in libstdc++, and not by a std::ios::Init object in every translation unit that includes . To avoid using uninitialized streams defined in an older libstdc++.so, translation units using the global iostreams should depend on the GLIBCXX_3.4.31 symver. Define std::cin as std::__io::cin and then export it as std::cin@@GLIBCXX_3.4.31 so that references to std::cin bind to the new symver. Also export it as @GLIBCXX_3.4 for backwards compatibility libstdc++-v3/ChangeLog: PR libstdc++/108969 * src/Makefile.am: Move globals_io.cc to here. * src/Makefile.in: Regenerate. * src/c++98/Makefile.am: Remove globals_io.cc from here. * src/c++98/Makefile.in: Regenerate. * src/c++98/globals_io.cc [_GLIBCXX_SYMVER_GNU] (cin): Adjust symbol name and then export with GLIBCXX_3.4.31 symver. (cout, cerr, clog, wcin, wcout, wcerr, wclog): Likewise. * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Regenerate. * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/pre/gnu.ver: Add iostream objects to new symver.
