c++/5821: Solaris: C++ compiler defines _XOPEN_SOURCE

[dpo@club-internet.fr]

>Number:         5821
>Category:       c++
>Synopsis:       Solaris: C++ compiler defines _XOPEN_SOURCE
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 03 14:56:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     dpo@club-internet.fr
>Release:        3.0.4
>Organization:
>Environment:
Solaris 8 on various Sparc machines
>Description:
I'm sorry to open a new bug report about the same
issue, but report #4915 was erroneously closed and
I don't know how to reopen it.

I won't discuss that libstdc++ may need to define
_XOPEN_SOURCE, although I'm curious why. I'll try
to remove it and see what happens for myself.

The problem is that one should not be defining
_XOPEN_SOURCE just because it's practical, for
example for building libstdc++. This is a bad
hack.

The default Solaris environment is to have none
of the _XOPEN_SOURCE_EXTENDED, _XOPEN_SOURCE,
__EXTENSIONS__, and other similar macros defined.
The C compiler is not modifying this default
environment and the C++ compiler should not either.
Just like the Sun C/C++ compilers.

If libstdc++ needs _XOPEN_SOURCE, then its build
system should be fixed so that _XOPEN_SOURCE is
defined when libstdc++ is built.

The problem is that defining _XOPEN_SOURCE triggers
lots of macro definitions like
	#define connect ...
that break sources that have always been compiling
with previous GNU compilers and Sun compilers. Well,
the sources can be modified of course. But the compiler
shouldn't modify the standard Solaris environment.
Let the user decide about it.
>How-To-Repeat:
$ gcc --version
3.0.2
$ cat foo.c
_XOPEN_SOURCE
$ gcc -E foo.c
# 1 "foo.c"
_XOPEN_SOURCE
$ 

$ g++ --version
3.0.2
$ cat foo.cc
_XOPEN_SOURCE
$ g++ -E foo.cc
# 1 "foo.cc"
500
$ 
>Fix:
Do not define _POSIX_SOURCE in the C++ compiler.
>Release-Note:
>Audit-Trail:
>Unformatted: