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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4