Red Hat Bugzilla – Bug 427617
Python.h unconditionally (re)defines _XOPEN_SOURCE
Last modified: 2008-01-31 18:08:39 EST
Description of problem: The Python.h header unconditionally defines _XOPEN_SOURCE, even if it's already defined. This causes redefinition errors in kdebindings (PyKDE4) with GCC 4.3. Version-Release number of selected component (if applicable): python-2.5.1-19.fc9 How reproducible: Always Steps to Reproduce: 1. Try building kdebindings in Rawhide with GCC 4.3. Actual results: In file included from /usr/include/python2.5/pyconfig.h:6, from /usr/include/python2.5/Python.h:8, from /usr/include/python2.5/sip.h:29, from /builddir/build/BUILD/kdebindings-3.97.0/x86_64-redhat-linux-gnu/python/pykde4/sip/solid/sipAPIsolid.h:28, from /builddir/build/BUILD/kdebindings-3.97.0/x86_64-redhat-linux-gnu/python/pykde4/sip/solid/sipsolidpart1.cpp:24: /usr/include/python2.5/pyconfig-64.h:944:1: error: "_XOPEN_SOURCE" redefined <command-line>: error: this is the location of the previous definition Expected results: No error
1. Python isn't exactly "well namespaced". 2. This file is providing information you can't get any other way, about what Python thinks the environment is. 3. pytohon*/*.h can/do trigger off these headers, so if you don't include Python.h _first_ (so the same features are visible) you are taking your compiles into your own hands IMO. ...feel free to file upstream, but this isn't something I want to change.
You're misunderstanding me: all I'm asking for is to change this: #define _XOPEN_SOURCE 600 to: #undef _XOPEN_SOURCE #define _XOPEN_SOURCE 600 or: #ifndef _XOPEN_SOURCE #define _XOPEN_SOURCE 600 #endif or maybe, to make it absolutely correct: #if !defined(_XOPEN_SOURCE) || _XOPEN_SOURCE<600 #undef _XOPEN_SOURCE #define _XOPEN_SOURCE 600 #endif all 3 of which will have absolutely no effect on programs which are already working right now, but will all fix kdebindings.
Oh, and to implement the #undef solution, adding: #undef _XOPEN_SOURCE to the top of the multilib hack /usr/include/python2.5/pyconfig.h (before including the wordsize-specific version) should be enough.
If you think that'll fix your problem, and cause no other problems, just do the #undef manually before including pyconfig.h To expand on point #3, it doesn't really matter what the header _changes_ _XOPEN_SOURCE to after features.h has been included and other parts of the the python headers can be relying on those features being enabled. So IMNSHO, anything using pyconfig.h should be including it first ... so that features.h gets setup correctly, or alternatively set everything up manually with the required #define's and #undef's (good luck with that). I understand that just putting this hack in pyconfig.h now will probably not do anything bad, but I'd have to make sure it continues to not do anything bad for each new upstream change we take ... and again, it gives people an unrealistic impression of how they can/should be using pyconfig.h.
1. This is generated code, we'd have to hack the sip generator to add the #undef, there's probably no way it can be fixed in kdebindings (except possibly by filtering out the -D_XOPEN_SOURCE from the command line, but I don't even know where this is set, probably a global cmake or KDE setting). 2. The sources _are_ including pyconfig.h first, the existing _XOPEN_SOURCE definition comes from the command line, not some other header. 3. I believe the correct solution is really to fix this in Python. A header must not blindly assume that feature macros like this are not set, many projects set these in the command line.
And 4. I don't understand this resistance to a change which will change absolutely nothing except to make projects which currently have redefinition errors from GCC 4.3 compile again (and makes them do the exact same thing they always did with GCC 4.1).
I can reassign this against sip, of course, but I believe adding the #undef in sip would be a crude hack around a bug in Python, which is likely to affect other Python-using software too, not just sip-generated bindings, and which is trivial to fix correctly.
Ok, if you can show me one other thing that puts -D_XOPEN_SOURCE on the command line ... I'll work around it for that case, but that's a pretty poor thing to do IMNSHO.
Googling for "-D_XOPEN_SOURCE" (with the quotes) returns thousands of results. Also searching for: "-D_XOPEN_SOURCE" Python.h in Google shows that at least (some versions of) SuperKaramba and mod_python are using both -D_XOPEN_SOURCE on the command line and #include <Python.h>. They may have their own workarounds for this issue though, and AFAIK this issue also only affects C++ (it's still a warning in C).
> Googling for "-D_XOPEN_SOURCE" (with the quotes) returns thousands of results. That's fine, any apps. not including pyconfig.h can do that without any problems. SuperKaramba isn't in Fedora and I've just done a mod_python mock build and it doesn't use _XOPEN_SOURCE on any files AFAICS.
FWIW kdebindings 4.0.1 now builds with GCC 4.3, so this must have been worked around somewhere in SIP or kdebindings itself.