Bug#126703: adding FAQ for extensively discussed issue about _GNU_SOURCE
tags 126703 + wontfix
tags 126703 + upstream
thanks
See
http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html
http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#3_5
On Solaris, g++ (but not gcc) always defines the preprocessor macro
_XOPEN_SOURCE. On GNU/Linux, the same happens with _GNU_SOURCE. (This
is not an exhaustive list; other macros and other platforms are also
affected.)
These macros are typically used in C library headers, guarding new
versions of functions from their older versions. The C++ standard
library includes the C standard library, but it requires the C90
version, which for backwards-compatability reasons is often not the
default for many vendors.
More to the point, the C++ standard requires behavior which is only
available on certain platforms after certain symbols are
defined. Usually the issue involves I/O-related typedefs. In order to
ensure correctness, the compiler simply predefines those symbols.
Note that it's not enough to #define them only when the library is
being built (during installation). Since we don't have an 'export'
keyword, much of the library exists as headers, which means that the
symbols must also be defined as your programs are parsed and compiled.
To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in the
gcc config headers for your target (and try changing them to see what
happens when building complicated code). You can also run "g++ -E -dM
- < /dev/null" to display a list of predefined macros for any
particular installation.
This has been discussed on the mailing lists quite a bit. See
http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris
This method is something of a wart. We'd like to find a cleaner
solution, but nobody yet has contributed the time.
Reply to: