[Bug libstdc++/114692] New: [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[Bug libstdc++/114692] New: [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[jakub at gcc dot gnu.org]

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

            Bug ID: 114692
           Summary: [14 Regression] Symbol versioning problem in GCC 14
                    libstdc++.so.6
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

I was just updating libstdc++ baseline_symbols.txt files from latest Fedora,
but seems we have a major issue.
While the CXXABI_1.3.15 symver is really new in GCC 14 and got one symbol,
I think GCC 13.1 shipped with GLIBCXX_3.4.31 as latest symver, but then we
applied
PR108969 fix for 13.2 and added one symbol to GLIBCXX_3.4.32 -
_ZSt21ios_base_library_initv.
But new symbols for GCC 14 should have been therefore added to GLIBCXX_3.4.33,
but they were actually added to GLIBCXX_3.4.32 which already shipped in GCC
13.2:
_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.32
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_m@@GLIBCXX_3.4.32
_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_m@@GLIBCXX_3.4.32
(or s/m@/j@/ or s/m@/y@/).

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
                 CC|                            |redi at gcc dot gnu.org
           Priority|P3                          |P1
           Keywords|                            |ABI

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-04-11
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
     Ever confirmed|0                           |1

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2521,9 +2521,12 @@ GLIBCXX_3.4.31 {
 GLIBCXX_3.4.32 {
     _ZSt21ios_base_library_initv;
    
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE11_S_allocateERS3_[jmy];
+} GLIBCXX_3.4.31;
+
+GLIBCXX_3.4.33 {
     # std::basic_file<>::native_handle()
     _ZNKSt12__basic_fileI[cw]E13native_handleEv;
-} GLIBCXX_3.4.31;
+} GLIBCXX_3.4.32;

 # Symbols in the support library (libsupc++) have their own tag.
 CXXABI_1.3 {

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 57927
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57927&action=edit
gcc14-libstdc++-baseline-updates.patch

This was what I've been preparing before noticing this issue.  If we change
libstdc++, that will need to be regenerated obviously (plus
libstdc++-v3/testsuite/util/testsuite_abi.cc updated of course).

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -2521,9 +2521,12 @@ GLIBCXX_3.4.31 {
>  GLIBCXX_3.4.32 {
>      _ZSt21ios_base_library_initv;
>     
> _ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE11_S_allocateER
> S3_[jmy];
> +} GLIBCXX_3.4.31;
> +
> +GLIBCXX_3.4.33 {
>      # std::basic_file<>::native_handle()
>      _ZNKSt12__basic_fileI[cw]E13native_handleEv;
> -} GLIBCXX_3.4.31;
> +} GLIBCXX_3.4.32;
>  
>  # Symbols in the support library (libsupc++) have their own tag.
>  CXXABI_1.3 {

_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE11_S_allocateERS3_[jmy];
wasn't in GCC 13.2 either, just _ZSt21ios_base_library_initv;

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The *shouldn't* have been added there though.

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
r14-739-gc62e945492afbb incorrectly added them to GLIBCXX_3.4.32 which should
have been frozen after 13.1 but it looks like I thought it was a new version
for 13.2/14.0

Then I must have thought 13.2 and 14.0 were both using that new version, they
should both have those new symbols.

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #4)
> This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(

Oops, guess too late then for those.  We'll need to consider 13.2 as a fuzzy
snapshot in between 13.1 and 13.3 then

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Jonathan Wakely from comment #4)
> > This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(
> 
> Oops, guess too late then for those.  We'll need to consider 13.2 as a fuzzy
> snapshot in between 13.1 and 13.3 then

GCC 13.1 was April 26th and didn't contain any GLIBCXX_3.4.32 I think;
then I've committed r13-7287 on April 28th, which added
_ZSt21ios_base_library_initv,
that was intentionally in a symver shared both by 13.2 and 14.1
then you've committed r13-7320 backport which added those 2 _S_allocate symbols
(with 3 size_t variants); and then 13.2 released on July 27th
So, the only bug is the _ZNKSt12__basic_fileI[cw]E13native_handleEv;
Though, surprisingly, the gnu.ver side says both Ic and Iw, while the
baseline_symbols.txt updates clearly indicate that only the Ic version is
exported.

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649260.html

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from GCC 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:1defe743aeb19532f6d6f4cab37e10f11467abd8

commit r14-9917-g1defe743aeb19532f6d6f4cab37e10f11467abd8
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Apr 11 12:28:25 2024 +0100

    libstdc++: Export std::__basic_file::native_handle as GLIBCXX_3.4.33
[PR114692]

    I added this new symbol in the wrong version. GLIBCXX_3.4.32 was
    already used for the GCC 13.2.0 release, so the new symbol should have
    been in a new GLIBCXX_3.4.33 version.

    Additionally, the pattern doesn't need to use [cw] because we only ever
    use __basic_file<char>, even for std::basic_filebuf<wchar_t>.

    libstdc++-v3/ChangeLog:

            PR libstdc++/114692
            * config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Move new exports for
            __basic_file::native_handle to ...
            (GLIBCXX_3.4.33): ... here. Adjust to not match wchar_t
            specialization, which isn't used.
            * testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.33 and update
            latest version check.

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[redi at gcc dot gnu.org]

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

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

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

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

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from GCC 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:6e25ca387fbbb412a2e498e28ea5db28e033a318

commit r15-277-g6e25ca387fbbb412a2e498e28ea5db28e033a318
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Apr 11 15:35:11 2024 +0100

    libstdc++: Update ABI test to disallow adding to released symbol versions

    If we update the list of "active" symbols versions now, rather than when
    adding a new symbol version, we will notice if new symbols get added to
    the wrong version (as in PR 114692).

    libstdc++-v3/ChangeLog:

            * testsuite/util/testsuite_abi.cc: Update latest versions to
            new versions that should be used in future.

[Bug libstdc++/114692] [14 Regression] Symbol versioning problem in GCC 14 libstdc++.so.6

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:788ccd269e0c32c33ce0c1359137fe1b35dc7a2d

commit r14-10205-g788ccd269e0c32c33ce0c1359137fe1b35dc7a2d
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Apr 11 15:35:11 2024 +0100

    libstdc++: Update ABI test to disallow adding to released symbol versions

    If we update the list of "active" symbols versions now, rather than when
    adding a new symbol version, we will notice if new symbols get added to
    the wrong version (as in PR 114692).

    libstdc++-v3/ChangeLog:

            * testsuite/util/testsuite_abi.cc: Update latest versions to
            new versions that should be used in future.

    (cherry picked from commit 6e25ca387fbbb412a2e498e28ea5db28e033a318)