[Python-Dev] use of #pragma GCC system_header to suppress _XOPEN_SOURCE warnings (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Fri Aug 6 22:04:49 CEST 2004

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 XOPENSOURCE, 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

More information about the Python-Dev mailing list