The following simple program fails to compile on FreeBSD 5.4: #define _POSIX_C_SOURCE 1 #include <iostream> g++ issues the following error message: /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl ude/c++/4.1.0/cwchar:166: error: '::vfwscanf' has not been declared /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl ude/c++/4.1.0/cwchar:170: error: '::vswscanf' has not been declared /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl ude/c++/4.1.0/cwchar:174: error: '::vwscanf' has not been declared /gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl ude/c++/4.1.0/cwchar:191: error: '::wcstof' has not been declared The FreeBSD 5.4 system compiler, which basically is GCC 3.4.2, has the same issue.
This is a target issue. The way we work around this on GNU/Linux is that we define _GNU_SOURCE all the time.
*** Bug 24013 has been marked as a duplicate of this bug. ***
The better way to fix this IMHO is to mirror how we fixed other conditionally missing symbols. Add a _DYNAMIC hook, add the support guards in various places where the HAVE_X guards exist, add a correctly written define in os_defines.h to describe the OS-level macro used to key the visibility of the "standard" function or other symbol. See the current FreeBSD os_defines.h for some examples. In my further opinion, this is merely a QoI issue (granted, annoying): The user defining a macro in implementor space may get this type of result. Regards, Loren
Historically, on some systems one had to define _POSIX_C_SOURCE to get at fileno(), which has been used by code generated by flex() and probably others.
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.
Closing 4.1 branch.
Closing 4.2 branch.
GCC 4.3.4 is being released, adjusting target milestone.
GCC 4.3.5 is being released, adjusting target milestone.
4.3 branch is being closed, moving to 4.4.7 target.
4.4 branch is being closed, moving to 4.5.4 target.
GCC 4.6.4 has been released and the branch has been closed.
The 4.7 branch is being closed, moving target milestone to 4.8.4.
This is not going to get fixed in the current branches, but if I get time later in stage 1 I plan to completely rework how we use feature test macros in libstdc++, so I'm updating the target milestone to 4.10
GCC 5.1 has been released.
GCC 5.2 is being released, adjusting target milestone to 5.3.
GCC 5.3 is being released, adjusting target milestone.
The (fairly large) changes needed to fix this didn't happen for gcc 5, or gcc6, adjusting target milestone.
(In reply to Gerald Pfeifer from comment #4) > Historically, on some systems one had to define _POSIX_C_SOURCE to get at > fileno(), which has been used by code generated by flex() and probably > others. Yes, but you don't have to define it to 1. If you define _POSIX_C_SOURCE to 199506L or set _XOPEN_SOURCE to 500 then I think the functions we use are available, as well as fileno.
Also, I assume this is only a problem for -std=c++98 or -std=gnu++98, because if the system headers don't declare those functions for C++11 and later dialects then that's a bug in those system headers.
(In reply to Jonathan Wakely from comment #19) > (In reply to Gerald Pfeifer from comment #4) > > Historically, on some systems one had to define _POSIX_C_SOURCE to get at > > fileno(), which has been used by code generated by flex() and probably > > others. > > Yes, but you don't have to define it to 1. If you define _POSIX_C_SOURCE to > 199506L or set _XOPEN_SOURCE to 500 then I think the functions we use are > available, as well as fileno. Correction: _POSIX_C_SOURCE=200112L or _XOPEN_SOURCE=600 should declare them.
(In reply to Jonathan Wakely from comment #20) > Also, I assume this is only a problem for -std=c++98 or -std=gnu++98, > because if the system headers don't declare those functions for C++11 and > later dialects then that's a bug in those system headers. That's not true, because we (rather bizarrely) do this: #if _GLIBCXX_HAVE_WCSTOF #undef wcstof #endif namespace std { #if _GLIBCXX_HAVE_WCSTOF using ::wcstof #endif } #if __cplusplus >= 201103L namespace std { #if _GLIBCXX_HAVE_WCSTOF using std::wcstof #endif } #endif This means we unconditionally try to declare them in namespace std, then for C++11 redeclare std::wcstof as std:wcstof (???).
Created attachment 41068 [details] Use dynamic checks for C99 <wchar.h> functions This fixes it and passes the testsuite on GNU/Linux and FreeBSD 11.0-RELEASE. Even though this bug is a regression, this is too late in the gcc-7 process to make a change like this. I'll commit it early for gcc-8 and backport it if it doesn't cause any problems.
The new tests fail on AIX 7.2: FAIL: 21_strings/headers/cwchar/24012.cc (test for excess errors) Excess errors: /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:224: error: '::wcstold' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:233: error: '::wcstoll' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:234: error: '::wcstoull' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:242: error: '__gnu_cxx::wcstold' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:243: error: '__gnu_cxx::wcstoll' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:244: error: '__gnu_cxx::wcstoull' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:268: error: '::wcstof' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:279: error: '::vfwscanf' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:290: error: '::vswscanf' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:300: error: '::vwscanf' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:310: error: '__gnu_cxx::wcstof' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:313: error: '__gnu_cxx::vfwscanf' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:316: error: '__gnu_cxx::vswscanf' has not been declared /home/jwakely/build/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/cwchar:319: error: '__gnu_cxx::vwscanf' has not been declared This isn't caused by the patch though, it always failed, for the same reason as FreeBSD. It doesn't pass with the patch because (unlike the BSDs) there's no dynamic check in config/os/aix/os_defines.h It looks like _ISOC99_SOURCE is the relevant macro for AIX. If that's not defined we don't get the C99 functions from <wchar.h>
GCC 8.1 has been released.
GCC 8.2 has been released.
The GCC 7 branch is being closed, re-targeting to GCC 8.4.
GCC 8.4.0 has been released, adjusting target milestone.
GCC 8 branch is being closed.
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
GCC 9 branch is being closed
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
GCC 10 branch is being closed.