Bug 2246731

Summary: g++ -m32 fails with error: invalid initialization...
Product: [Fedora] Fedora Reporter: Patrick Laimbock <patrick>
Component: glibc32Assignee: Florian Weimer <fweimer>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 39CC: codonell, coryan, dmalcolm, fweimer, jakub, jlaw, jwakely, mccannd, mcermak, mpolacek, msebor, nickc, rwahl, sam, sipoyare, tom
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
URL: https://download.copr.fedorainfracloud.org/results/patrickl/yabridge/fedora-39-x86_64/06573424-yabridge/builder-live.log.gz
Whiteboard:
Fixed In Version: glibc32-2.38-10.1.fc39 glibc32-2.38-10.1.fc40 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-12-08 01:39:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
config.log snippet for C99 <stdlib.h> checks
none
config.log snippet for arc4random checks none

Description Patrick Laimbock 2023-10-28 16:44:51 UTC
Reproducable as follows:

$ cat test.cpp
#include <string>

int main() {
    std::stoi("4");
}

$ g++ -m32 test.cpp
test.cpp: In function ‘int main()’:
test.cpp:4:15: error: invalid initialization of reference of type ‘const std::wstring&’ {aka ‘const std::__cxx11::basic_string<wchar_t>&’} from expression of type ‘const char [2]’
    4 |     std::stoi("4");
      |               ^~~
In file included from /usr/include/c++/13/string:54,
                 from test.cpp:1:
/usr/include/c++/13/bits/basic_string.h:4260:23: note: in passing argument 1 of ‘int std::__cxx11::stoi(const std::wstring&, std::size_t*, int)’
 4260 |   stoi(const wstring& __str, size_t* __idx = 0, int __base = 10)

Reproducible: Always

Steps to Reproduce:
1. g++ -m32 test.cpp
2. error

Actual Results:  
$ g++ -m32 test.cpp
test.cpp: In function ‘int main()’:
test.cpp:4:15: error: invalid initialization of reference of type ‘const std::wstring&’ {aka ‘const std::__cxx11::basic_string<wchar_t>&’} from expression of type ‘const char [2]’
    4 |     std::stoi("4");
      |               ^~~
In file included from /usr/include/c++/13/string:54,
from test.cpp:1:
/usr/include/c++/13/bits/basic_string.h:4260:23: note: in passing argument 1 of ‘int std::__cxx11::stoi(const std::wstring&, std::size_t*, int)’
 4260 |   stoi(const wstring& __str, size_t* __idx = 0, int __base = 10)

Expected Results:  
It compiles.

There was no issue building yabridge referenced in the URL above on F38 x86_64. 

The developer of yabridge provided test.cpp code to reproduce. I was told that Arch has no issue with this code while it has the same g++ version 13.2.1 except that Fedora 39's gcc-13.2.1-4 has a number of patches.

https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/blob/13.2.1-3/PKGBUILD?ref_type=tags

Comment 1 Jonathan Wakely 2023-10-28 21:54:15 UTC
For some reason this definition is missing from the 32-bit bits/c++config.h

#define _GLIBCXX11_USE_C99_STDLIB 1

That is needed for the narrow version of std::stoi to be declared.

Comment 2 Jonathan Wakely 2023-10-31 15:38:07 UTC
This is the check that seems to be failing for -m32

    # Check for the existence in <stdlib.h> of lldiv_t, et. al.
    AC_CACHE_CHECK([for ISO C99 support in <stdlib.h> for C++11],
      glibcxx_cv_c99_stdlib_cxx11, [
      GCC_TRY_COMPILE_OR_LINK(
        [#include <stdlib.h>
         volatile float f;
         volatile long double ld;
         volatile unsigned long long ll;
         lldiv_t mydivt;],
        [char* tmp;
         f = strtof("gnu", &tmp);
         ld = strtold("gnu", &tmp);
         ll = strtoll("gnu", &tmp, 10);
         ll = strtoull("gnu", &tmp, 10);
         ll = llabs(10);
         mydivt = lldiv(10,1);
         ll = mydivt.quot;
         ll = mydivt.rem;
         ll = atoll("10");
         _Exit(0);
        ], [glibcxx_cv_c99_stdlib_cxx11=yes], [glibcxx_cv_c99_stdlib_cxx11=no])
    ])
    if test x"$glibcxx_cv_c99_stdlib_cxx11" = x"yes"; then
      AC_DEFINE(_GLIBCXX11_USE_C99_STDLIB, 1,
        [Define if C99 functions or macros in <stdlib.h> should be imported
        in <cstdlib> in namespace std for C++11.])
    fi

Comment 3 Jonathan Wakely 2023-11-01 11:44:22 UTC
(In reply to Patrick Laimbock from comment #0)
> The developer of yabridge provided test.cpp code to reproduce. I was told
> that Arch has no issue with this code while it has the same g++ version
> 13.2.1 except that Fedora 39's gcc-13.2.1-4 has a number of patches.

Are you actually using gcc-13.2.1-4 or 13.2.1-3? What is the output of 'rpm -q gcc'?

Comment 4 Patrick Laimbock 2023-11-01 12:33:28 UTC
patrick@x1-wifi:~$ rpm -q gcc
gcc-13.2.1-4.fc39.x86_64

Comment 5 Jonathan Wakely 2023-11-01 19:44:55 UTC
The autoconf checks for the 32-bit multilib fail due to this:

/usr/bin/ld: /tmp/cc8Gf6qg.o: in function `main':
/builddir/build/BUILD/gcc-13.2.1-20231011/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/conftest.cpp:53: undefined reference to `__isoc23_strtoll'
/usr/bin/ld: /builddir/build/BUILD/gcc-13.2.1-20231011/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/conftest.cpp:54: undefined reference to `__isoc23_strtoull'
/usr/bin/ld: /tmp/cc8Gf6qg.o: in function `main':
/usr/include/stdlib.h:495: undefined reference to `__isoc23_strtoll'
collect2: error: ld returned 1 exit status

Comment 6 Jonathan Wakely 2023-11-01 19:51:41 UTC
There's also this unexpected failure for -m32:

/builddir/build/BUILD/gcc-13.2.1-20231011/obj-x86_64-redhat-linux/x86_64-redhat-linux/32/libstdc++-v3/conftest.cpp:214: undefined reference to `arc4random'

Comment 7 Jonathan Wakely 2023-11-01 19:52:50 UTC
Created attachment 1996630 [details]
config.log snippet for C99 <stdlib.h> checks

Comment 8 Jonathan Wakely 2023-11-01 19:53:28 UTC
Created attachment 1996631 [details]
config.log snippet for arc4random checks

Comment 9 Jakub Jelinek 2023-11-01 20:45:14 UTC
So most likely a glibc32 bug then...

Comment 10 Jonathan Wakely 2023-11-01 23:31:09 UTC
Yes, it looks like a new glibc32 is needed for all Fedora releases.

The missing arc4random symbol is present in f37 and f38, but only causes problems if you try to use std::random_device("arc4random").

The missing __isoc23_strtoll symbol seems to be new in f39 and breaks much more widely-used functionality in libstdc++.

Comment 11 Jonathan Wakely 2023-11-10 21:44:29 UTC
*** Bug 2249136 has been marked as a duplicate of this bug. ***

Comment 12 Jonathan Wakely 2023-12-04 12:08:58 UTC
*** Bug 2252729 has been marked as a duplicate of this bug. ***

Comment 13 Ronald Wahl 2023-12-04 14:24:57 UTC
In the end gcc.i686 will also need a rebuild after glibc.i686 is fixed because libstdc++ package is build from it.

Comment 14 Fedora Update System 2023-12-06 11:46:37 UTC
FEDORA-2023-1c6b112a75 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-1c6b112a75

Comment 15 Jakub Jelinek 2023-12-06 11:49:34 UTC
(In reply to Ronald Wahl from comment #13)
> In the end gcc.i686 will also need a rebuild after glibc.i686 is fixed
> because libstdc++ package is build from it.

That doesn't make any sense.  glibc.i686 has never been broken like that.  The bug was that glibc32 has not been updated for quite a while and newer glibc headers started using something that glibc32 didn't provide.

Anyway, F39 errata with gcc rebuilt against newer glibc32 has been just filed.

Comment 16 Ronald Wahl 2023-12-06 17:11:20 UTC
(In reply to Jakub Jelinek from comment #15)
> (In reply to Ronald Wahl from comment #13)
> > In the end gcc.i686 will also need a rebuild after glibc.i686 is fixed
> > because libstdc++ package is build from it.
> 
> That doesn't make any sense.  glibc.i686 has never been broken like that. 
> The bug was that glibc32 has not been updated for quite a while and newer
> glibc headers started using something that glibc32 didn't provide.

I assumed glibc32 meant the same as glibc.i686 but it seems something special for gcc. Didn't know that.
Actually as long as libstdc++ is fixed everything is fine for me.

> Anyway, F39 errata with gcc rebuilt against newer glibc32 has been just
> filed.

Great. Thx!

Comment 17 Fedora Update System 2023-12-07 01:49:10 UTC
FEDORA-2023-1c6b112a75 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-1c6b112a75`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-1c6b112a75

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 18 Jakub Jelinek 2023-12-07 10:35:05 UTC
*** Bug 2253421 has been marked as a duplicate of this bug. ***

Comment 19 Fedora Update System 2023-12-08 01:39:15 UTC
FEDORA-2023-1c6b112a75 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.