[Bug libstdc++/108969] New: [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[Bug libstdc++/108969] New: [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

            Bug ID: 108969
           Summary: [13 Regression] Initializing iostreams in the library
                    needs a GLIBCXX_3.4.31 versioned symbol
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ABI
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The fix for PR 44952 is an ABI change because code compiled with GCC 13 relies
on the init happening once in the library. If a binary compiled with GCC 13
uses libstdc++.so.6.0.30 at runtime then it will segfault when trying to use
the streams. Even though this scenario is unsupported, it would be much better
to get an error from ld.so

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2023-02-28
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=44952
   Target Milestone|---                         |13.0

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

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> ---
Can we do it without actually introducing some code to what gets executed?
Like,
asm (".global _ZN9__gnu_cxx19needs_iostream_initE");
in place where it was done before?
The above results in the symbol being listed in .symtab, but no actual runtime
relocations against it.

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
--- 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 __has_attribute(symver) && !_GLIBCXX_INLINE_VERSION
+# define SYMVER(sym) __attribute__((symver(#sym "@@GLIBCXX_3.4.31")))
+#else
+# define SYMVER(sym)
+#endif
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -53,20 +59,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __attribute__ ((aligned(__alignof__(istream))));
   typedef char fake_ostream[sizeof(ostream)]
   __attribute__ ((aligned(__alignof__(ostream))));
-  fake_istream cin;
-  fake_ostream cout;
-  fake_ostream cerr;
-  fake_ostream clog;
+  SYMVER(_ZSt3cin) fake_istream cin;
+  SYMVER(_ZSt4cout) fake_ostream cout;
+  SYMVER(_ZSt4cerr) fake_ostream cerr;
+  SYMVER(_ZSt4clog) fake_ostream clog;

 #ifdef _GLIBCXX_USE_WCHAR_T
   typedef char fake_wistream[sizeof(wistream)]
   __attribute__ ((aligned(__alignof__(wistream))));
   typedef char fake_wostream[sizeof(wostream)]
   __attribute__ ((aligned(__alignof__(wostream))));
-  fake_wistream wcin;
-  fake_wostream wcout;
-  fake_wostream wcerr;
-  fake_wostream wclog;
+  SYMVER(_ZSt4wcin) fake_wistream wcin;
+  SYMVER(_ZSt5wcout) fake_wostream wcout;
+  SYMVER(_ZSt5wcerr) fake_wostream wcerr;
+  SYMVER(_ZSt5wclog) fake_wostream wclog;
 #endif

 #include "ios_base_init.h"

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The patch above means that a program using cout (or any of the standard
streams) gets:

0000000000404040 B _ZSt4cout@GLIBCXX_3.4.31

instead of:

0000000000404040 B _ZSt4cout@GLIBCXX_3.4

And then it fails to run with the older libstdc++.so:

./a.out: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.31' not found (required by
./a.out)


But I agree that it's not a complete solution for all targets, just a quick fix
for linux distros where this is most likely to cause problems today.

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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).

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #6 from Florian Weimer <fw at gcc dot gnu.org> ---
(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:
>  // _GLIBCXX_ASM_SYMVER(currentname, oldname, GLIBCXX_3.2)
>  
> +#if __has_attribute(symver) && !_GLIBCXX_INLINE_VERSION
> +# define SYMVER(sym) __attribute__((symver(#sym "@@GLIBCXX_3.4.31")))
> +#else
> +# define SYMVER(sym)
> +#endif

Is there anything that prevents these symbol versions getting added for
libstdc++.a? I think that could be problematic because a custom DSO typically
will not have a version node for GLIBCXX_3.4.31.

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think they're exported correctly with both versions:

$ nm -D  --defined-only  src/.libs/libstdc++.so.6.0.31 | grep '_ZSt[345]c'
000000000025d7a0 B _ZSt3cin@@GLIBCXX_3.4
000000000025d7a0 B _ZSt3cin@@GLIBCXX_3.4.31
000000000025d560 B _ZSt4cerr@@GLIBCXX_3.4
000000000025d560 B _ZSt4cerr@@GLIBCXX_3.4.31
000000000025d440 B _ZSt4clog@@GLIBCXX_3.4
000000000025d440 B _ZSt4clog@@GLIBCXX_3.4.31
000000000025d680 B _ZSt4cout@@GLIBCXX_3.4.31
000000000025d680 B _ZSt4cout@@GLIBCXX_3.4

But Florian's right, they're in the .a too.

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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'
> 000000000025d7a0 B _ZSt3cin@@GLIBCXX_3.4
> 000000000025d7a0 B _ZSt3cin@@GLIBCXX_3.4.31
> 000000000025d560 B _ZSt4cerr@@GLIBCXX_3.4
> 000000000025d560 B _ZSt4cerr@@GLIBCXX_3.4.31
> 000000000025d440 B _ZSt4clog@@GLIBCXX_3.4
> 000000000025d440 B _ZSt4clog@@GLIBCXX_3.4.31
> 000000000025d680 B _ZSt4cout@@GLIBCXX_3.4.31
> 000000000025d680 B _ZSt4cout@@GLIBCXX_3.4

Note, the GLIBCXX_3.4 ones should be @, not @@.

> But Florian's right, they're in the .a too.

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.

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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 +43,12 @@
> >  // In macro form:
> >  // _GLIBCXX_ASM_SYMVER(currentname, oldname, GLIBCXX_3.2)
> >  
> > +#if __has_attribute(symver) && !_GLIBCXX_INLINE_VERSION
> > +# define SYMVER(sym) __attribute__((symver(#sym "@@GLIBCXX_3.4.31")))
> > +#else
> > +# define SYMVER(sym)
> > +#endif
> 
> Is there anything that prevents these symbol versions getting added for
> libstdc++.a? I think that could be problematic because a custom DSO
> typically will not have a version node for GLIBCXX_3.4.31.

Can we make everything hidden in libstdc++.a?  If somebody builds a DSO
with -static-libstdc++ then he very likely doesn't want to export libstdc++
symbols?

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.

We have a handful of objects which are built without --tag disable-shared in
LTCXXCOMPILE, see src/Makefile.am

So if we use that approach for globals_io.cc then we can check if
_GLIBCXX_SHARED is defined to tell whether we're going into the .so or not.

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #11 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Would it make sense to backport a "transition" version of r13-3707 to the
release branches, one that just adds the static __ioinit object into the
compiled library (without the init_priority attribute, since we only care about
dynamic linking compatibility) and doesn't remove the static object from
<iostream>?

That way, a program compiled with GCC 13 and linked against libstdc++ 12.3
would still work w.r.t. stream initialization.  And this library-side
initialization should be safe since the ios_base::Init cdtors are idempotent.

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
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 present in the
oder DSOs) so the dynamic link will fail?

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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 present in the
> oder DSOs) so the dynamic link will fail?


I believe that is what we're discussing here, how to arrange that such symbols
would be
those mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969#c7
That solution doesn't work everywhere, because only GNU symbol versioning
allows the
same symbol to be exported at multiple symbol versions.
So, for Solaris we can just not do anything, or come up with some other
solution
(like the artificial use of a symbol through asm in the header file).

[Bug libstdc++/108969] [13 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ping.

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:b7c54e3f48086c29179f7765a35c381de5109a0a

commit r14-43-gb7c54e3f48086c29179f7765a35c381de5109a0a
Author: Jonathan Wakely <jwakely@redhat.com>
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 <iostream>. 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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:762be0646bf96761ce68a9e06ab60c453e0963d0

commit r13-7217-g762be0646bf96761ce68a9e06ab60c453e0963d0
Author: Jonathan Wakely <jwakely@redhat.com>
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 <iostream>. 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

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for 13.1

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:6067ae4557a3a7e5b08359e78a29b8a9d5dfedce

commit r14-46-g6067ae4557a3a7e5b08359e78a29b8a9d5dfedce
Author: Jonathan Wakely <jwakely@redhat.com>
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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:ed933888e680384e1e7af361b20dd484ad424f7d

commit r13-7218-ged933888e680384e1e7af361b20dd484ad424f7d
Author: Jonathan Wakely <jwakely@redhat.com>
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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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
000000000040401c  0000000400000005 R_X86_64_COPY          000000000040401c
_ZSt4cerr@GLIBCXX_3.4 + 0
     3: 000000000040401c     4 OBJECT  WEAK   DEFAULT   23
_ZSt4cerr@GLIBCXX_3.4.31 (3)
     4: 000000000040401c     4 OBJECT  GLOBAL DEFAULT   23
_ZSt4cerr@GLIBCXX_3.4 (4)
    58: 000000000040401c     4 OBJECT  WEAK   DEFAULT   23
_ZSt4cerr@GLIBCXX_3.4.31
    59: 000000000040401c     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

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #21 from Sam James <sjames at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #23 from Florian Weimer <fw at gcc dot gnu.org> ---
(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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |13.2

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
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

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bremende55 at gmail dot com

--- Comment #26 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
*** 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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #27 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:9a41d2cdbcd2af77a3a91a840a3a13f0eb39971b

commit r14-321-g9a41d2cdbcd2af77a3a91a840a3a13f0eb39971b
Author: Jakub Jelinek <jakub@redhat.com>
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 <iostream> 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 <iostream> expects the library to initialize it and the library
    expects code including <iostream> 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 <iostream> 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 <iostream>

    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: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_ZSt21ios_base_library_initv@GLIBCXX_3.4.32 (4)
        71: 0000000000000000     0 FUNC    GLOBAL 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  <jakub@redhat.com>

            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

[romain.geissler at amadeus dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

Romain Geissler <romain.geissler at amadeus dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |romain.geissler at amadeus dot com

--- Comment #28 from Romain Geissler <romain.geissler at amadeus dot com> ---
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
<iostream>) 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

[romain.geissler at amadeus dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #29 from Romain Geissler <romain.geissler at amadeus dot com> ---
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

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #30 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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

[romain.geissler at amadeus dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #31 from Romain Geissler <romain.geissler at amadeus dot com> ---
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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

--- Comment #32 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:9c9061e0418ded473672069aac43b25f6fd491b8

commit r13-7287-g9c9061e0418ded473672069aac43b25f6fd491b8
Author: Jakub Jelinek <jakub@redhat.com>
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 <iostream> 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 <iostream> expects the library to initialize it and the library
    expects code including <iostream> 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 <iostream> 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 <iostream>

    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: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
_ZSt21ios_base_library_initv@GLIBCXX_3.4.32 (4)
        71: 0000000000000000     0 FUNC    GLOBAL 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  <jakub@redhat.com>

            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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|REOPENED                    |RESOLVED

--- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now (for Linux targets) for 13.2/14.1 and later.