This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author enchanter
Recipients enchanter
Date 2010-01-06.16:42:03
SpamBayes Score 1.08289e-08
Marked as misclassified No
Message-id <1262796125.66.0.294403440814.issue6299@psf.upfronthosting.co.za>
In-reply-to
Content
This still happens in 2.6.3 and 2.6.4 so I spent some time looking at it.

It's happening because of a combination of issues, but ultimately it's because python's build isn't making certain that it's including its private copy of expat.h and expat_external.h.

Basically, this

-DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI -I/local/src/RPM/BUILD/Python-2.6.4/./Modules/expat

should *precede* CFLAGS, rather than coming after it.

To reproduce:

- install expat 2.0.1 under /usr/local or /opt (or any prefix other
  than just /usr)
- include -I$prefix/include in CFLAGS when configuring Python
- make

This results in the special includes for python's local copy of the expat sources being *after* the -I/usr/local/include on the command line, so the copy of expat.h and expat_external.h in /usr/local/include are found first, and that causes the link failure when generating pyexpat.so.

Note that it's not just as simple as not including -I/usr/local/include in CFLAGS, because there may be other locally-installed packages that python should be finding to build other modules.

The real fix is for Python's build machinery to make certain that the special includes for Python's private expat sources precede CFLAGS.
History
Date User Action Args
2010-01-06 16:42:05enchantersetrecipients: + enchanter
2010-01-06 16:42:05enchantersetmessageid: <1262796125.66.0.294403440814.issue6299@psf.upfronthosting.co.za>
2010-01-06 16:42:03enchanterlinkissue6299 messages
2010-01-06 16:42:03enchantercreate