Tim Mooney <enchan...@users.sourceforge.net> added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6299> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
