Bug 427617 - Python.h unconditionally (re)defines _XOPEN_SOURCE
Python.h unconditionally (re)defines _XOPEN_SOURCE
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: python (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: James Antill
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-05 08:34 EST by Kevin Kofler
Modified: 2008-01-31 18:08 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-07 13:04:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kevin Kofler 2008-01-05 08:34:09 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
Comment 1 James Antill 2008-01-05 18:58:52 EST
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.
Comment 2 Kevin Kofler 2008-01-05 19:06:32 EST
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.
Comment 3 Kevin Kofler 2008-01-05 19:11:09 EST
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.
Comment 4 James Antill 2008-01-06 09:33:12 EST
 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.
Comment 5 Kevin Kofler 2008-01-06 16:19:26 EST
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.
Comment 6 Kevin Kofler 2008-01-06 16:21:01 EST
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).
Comment 7 Kevin Kofler 2008-01-06 16:26:44 EST
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.
Comment 8 James Antill 2008-01-06 17:18:08 EST
 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.
Comment 9 Kevin Kofler 2008-01-06 18:44:20 EST
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).
Comment 10 James Antill 2008-01-07 13:04:33 EST
> 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.
Comment 11 Kevin Kofler 2008-01-31 18:08:39 EST
FWIW kdebindings 4.0.1 now builds with GCC 4.3, so this must have been worked 
around somewhere in SIP or kdebindings itself.

Note You need to log in before you can comment on or make changes to this bug.