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
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.
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
(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'?
patrick@x1-wifi:~$ rpm -q gcc gcc-13.2.1-4.fc39.x86_64
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
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'
Created attachment 1996630 [details] config.log snippet for C99 <stdlib.h> checks
Created attachment 1996631 [details] config.log snippet for arc4random checks
So most likely a glibc32 bug then...
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++.
*** Bug 2249136 has been marked as a duplicate of this bug. ***
*** Bug 2252729 has been marked as a duplicate of this bug. ***
In the end gcc.i686 will also need a rebuild after glibc.i686 is fixed because libstdc++ package is build from it.
FEDORA-2023-1c6b112a75 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-1c6b112a75
(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.
(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!
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.
*** Bug 2253421 has been marked as a duplicate of this bug. ***
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.