Bug 2252729 - libstdc++ does not define _GLIBCXX_USE_C99* macros anymore causing build errors
Summary: libstdc++ does not define _GLIBCXX_USE_C99* macros anymore causing build errors
Keywords:
Status: CLOSED DUPLICATE of bug 2246731
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 39
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-12-04 11:02 UTC by Ronald Wahl
Modified: 2023-12-04 12:08 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2023-12-04 12:08:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ronald Wahl 2023-12-04 11:02:25 UTC
Hi,

in Fedora 39 I got some build errors with some of my C++ code:

test.cpp:23:23:error: invalid initialization of reference of type ‘const std::wstring&’ {aka ‘const std::__cxx11::basic_string<wchar_t>&’} from expression of type ‘const std::string’ {aka ‘const std::__cxx11::basic_string<char>’}
   23 |         v = std::stod(str, &pos);
      |                       ^~~

Looks like the stod is not available for basic_string<char>. 

When I define _GLIBCXX_USE_C99_STDLIB to 1 it works again.

I noticed a difference between Fedora 38 and 39 that look like that C99 features have been disabled in Fedora 39 and this looks like a mistake:

--- /usr/include/c++/13/x86_64-redhat-linux/bits/c++config.h	2023-10-11 02:00:00.000000000 +0200
+++ c++config.h	2023-12-04 11:50:32.912063665 +0100
@@ -38,7 +38,7 @@
 #define _GLIBCXX_RELEASE 13
 
 // The datestamp of the C++ library in compressed ISO date format.
-#define __GLIBCXX__ 20231011
+#define __GLIBCXX__ 20230918
 
 // Macros for various attributes.
 //   _GLIBCXX_PURE
@@ -1676,11 +1676,11 @@
 
 /* Define if C99 functions or macros in <stdio.h> should be imported in
    <cstdio> in namespace std for C++11. */
-#define _GLIBCXX11_USE_C99_STDIO 1
+/* #undef _GLIBCXX11_USE_C99_STDIO */
 
 /* Define if C99 functions or macros in <stdlib.h> should be imported in
    <cstdlib> in namespace std for C++11. */
-#define _GLIBCXX11_USE_C99_STDLIB 1
+/* #undef _GLIBCXX11_USE_C99_STDLIB */
 
 /* Define if C99 functions or macros in <wchar.h> should be imported in
    <cwchar> in namespace std for C++11. */
@@ -1701,7 +1701,7 @@
 
 /* Define if C99 functions or macros in <stdlib.h> should be imported in
    <cstdlib> in namespace std for C++98. */
-#define _GLIBCXX98_USE_C99_STDLIB 1
+/* #undef _GLIBCXX98_USE_C99_STDLIB */
 
 /* Define if C99 functions or macros in <wchar.h> should be imported in
    <cwchar> in namespace std for C++98. */
@@ -1783,7 +1783,7 @@
 
 /* Define if C99 functions or macros from <wchar.h>, <math.h>, <complex.h>,
    <stdio.h>, and <stdlib.h> can be used or exposed. */
-#define _GLIBCXX_USE_C99 1
+/* #undef _GLIBCXX_USE_C99 */
 
 /* Define if C99 functions in <complex.h> should be used in <tr1/complex>.
    Using compiler builtins for these functions requires corresponding C99
@@ -2319,7 +2319,7 @@
 #define _GLIBCXX_RELEASE 13
 
 // The datestamp of the C++ library in compressed ISO date format.
-#define __GLIBCXX__ 20231011
+#define __GLIBCXX__ 20230918
 
 // Macros for various attributes.
 //   _GLIBCXX_PURE

Reproducible: Always

Comment 1 Jonathan Wakely 2023-12-04 12:08:58 UTC
Thanks for the report, this is already known.

*** This bug has been marked as a duplicate of bug 2246731 ***


Note You need to log in before you can comment on or make changes to this bug.