[Python-Dev] use of #pragma GCC system_header to suppress _XOPEN_SOURCE warnings

["Martin v. Löwis"]

Skip Montanaro wrote:
> I was shown today that g++ defines that macro internally (I misspoke when I
> referred to gcc yesterday - I tend to lump them together and forget that C++
> is a different language than C), at least 3.3.2 on Solaris/Intel does.

Ah, that one.

I don't think it is a goal that Python generates no warnings if compiled 
with a C++ compiler (I don't think you actually *can* compile all of 
Python with a C++ compiler).

> This suggests that Sun expects the application or its build tools to define
> _XOPEN_SOURCE, not the compiler or its header files.  That suggests a bug in
> g++.

Indeed, and I believe this is a known bug. g++ needs to define
_XOPEN_SOURCE so that some of Sun's system headers declare a number of
prototypes which are then referred-to in inline functions of libstdc++
header files; I think this is about wchar_t functions, thread functions,
or C99 floating-point functions. It's not clear whether this is Sun's
or g++' fault - g++ should probably fixinclude the system headers
appropriately, but doesn't.

This gives us a number of options:
1. On Solaris, define _XOPEN_SOURCE to the same value that g++ uses.
    This should then cause no redefinition, but might cause some
    functions go away. We would need an autoconf test to find out
    what the value of _XOPEN_SOURCE is that g++ uses.
2. As g++ is only used to compile main.cc, we could #undef
    _XOPEN_SOURCE there - either the one of g++, or our own one
    (appropriately commented, of course).
3. We could advise users to explicitly compile --without-cxx
    on Solaris when using g++. I believe it is not actually needed,
    but our autoconf test is not strong enough to find out, and
    errs on the side of building main.cc with a C++ compiler if
    one is available and the user hasn't requested that it won't.

Regards,
Martin