Bug 427617 - Python.h unconditionally (re)defines _XOPEN_SOURCE
Summary: Python.h unconditionally (re)defines _XOPEN_SOURCE
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: python
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: James Antill
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-01-05 13:34 UTC by Kevin Kofler
Modified: 2008-01-31 23:08 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-01-07 18:04:33 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Kevin Kofler 2008-01-05 13:34:09 UTC
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 23:58:52 UTC
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-06 00:06:32 UTC
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-06 00:11:09 UTC
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 14:33:12 UTC
 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 21:19:26 UTC
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 21:21:01 UTC
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 21:26:44 UTC
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 22:18:08 UTC
 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 23:44:20 UTC
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 18:04:33 UTC
> 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 23:08:39 UTC
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.