libstdc++ should define `std::to_string(double)` after `#include <string>`. The version of `libstdc++` for 64-bits does so. The version of `libstdc++` for 32-bits does not. This is a problem. Reproducible: Always Steps to Reproduce: 1. dnf makecache && dnf install -y gcc-c++ glibc-devel libstdc++-devel glibc-devel.i686 libstdc++-devel.i686 2. printf "#include <string>\n#include <iostream>\n\nint main() { std::cout << std::to_string(1.0) << std::endl; }\n" >test.cc 3. g++ -m32 test.cc Actual Results: test.cc: In function ‘int main()’: test.cc:4:41: error: call of overloaded ‘to_string(double)’ is ambiguous 4 | int main() { std::cout << std::to_string(1.0) << std::endl; } | ~~~~~~~~~~~~~~^~~~~ In file included from /usr/include/c++/13/string:54, from test.cc:1: /usr/include/c++/13/bits/basic_string.h:4150:3: note: candidate: ‘std::string std::__cxx11::to_string(int)’ 4150 | to_string(int __val) | ^~~~~~~~~ Expected Results: A successful compilation without errors. It seems `std::to_string()` overloads for `float`, `double` and `long double` are protected by a `#if _GLIBCXX_USE_C99_STDIO`: https://github.com/gcc-mirror/gcc/blob/c891d8dc23e1a46ad9f3e757d09e57b500d40044/libstdc%2B%2B-v3/include/bits/basic_string.h#L4224-L4235 That macro is defined in terms of `_GLIBCXX11_USE_C99_STDIO`: echo '#include <string>' | g++ -m32 -x c++ -dM -E - | grep _GLIBCXX_USE_C99_STDIO #define _GLIBCXX_USE_C99_STDIO _GLIBCXX11_USE_C99_STDIO That macro appears in the 64-bit version of `bits/c++config.h`: grep _GLIBCXX11_USE_C99_STDIO /usr/include/c++/13/x86_64-redhat-linux/bits/c++config.h # define _GLIBCXX_USE_C99_STDIO _GLIBCXX11_USE_C99_STDIO /* #undef _GLIBCXX11_USE_C99_STDIO */ # define _GLIBCXX_USE_C99_STDIO _GLIBCXX11_USE_C99_STDIO #define _GLIBCXX11_USE_C99_STDIO 1 But does not appear in the 32-bit version: grep _GLIBCXX11_USE_C99_STDIO /usr/include/c++/13/x86_64-redhat-linux/32/bits/c++config.h # define _GLIBCXX_USE_C99_STDIO _GLIBCXX11_USE_C99_STDIO /* #undef _GLIBCXX11_USE_C99_STDIO */ ----- FWIW, this compiles successfully with Fedora:38.
*** This bug has been marked as a duplicate of bug 2246731 ***