The issue with confliciting expat versions has poped up again in python 3. http://bugs.python.org/issue1295808 It looks like the fix for this was removed when upgrading to expat 2.1 in http://hg.python.org/cpython/rev/e4dc8be9a72f on Sat, 14 Jul 2012 14:12:35 -0700 Gregory P. Smith --- a/Modules/expat/expat_external.h /* Namespace external symbols to allow multiple libexpat version to - co-exist. */ -#include "pyexpatns.h" Same backtrace as before. #0 0x0000003507481321 in __strlen_sse2 () from /lib64/libc.so.6 #1 0x00007facace1b0d0 in PyUnicode_FromString (u=0x0) at Objects/unicodeobject.c:1824 #2 0x00007facaceefddc in PyModule_AddStringConstant (m=0x7fac9c7cf678, name=0x7fac9c5ab2e3 "XML_ERROR_UNBOUND_PREFIX", value=0x0) at Python/modsupport.c:554 #3 0x00007fac9c582f31 in PyInit_pyexpat () at /home/hex/Downloads/Python-3.Modules/pyexpat.c:1870 #4 0x00007facacee8f89 in _PyImport_LoadDynamicModule (name=0x7fac9c7db450, path=0x7fac9cdf9928, fp=0x0)
Hello, it seems that the solution to this issue causes the failure to compile the pyexpat extension in my case. If I do not include pyexpatns.h in expat_external.h then the compile succeeeds. I will attach the output for both cases. There was no problem with 3.4.0b3. My environment: Python 3.4.0 Red Hat Linux 6.4 GCC 4.8.2 it makes no difference if I use --with-system-expat or without.
Hi Peter, Thanks for taking the time to report your issue. I just tried on fresh up-to-date CentOS 6 and I could not reproduce the issue. However, I think I figured out what went wrong. I can see you are supplying custom -I and -L paths (-I/apps/prod/releases/3.0/include ...) I suspect that when compiling pyexpat.c (in Modules/) the header file expat.h is picked up from this location before the bundled expat.h (in Modules/expat/) is found. But when compiling xmlparse.c (in Modules/expat/) the bundled header file expat.h *is* used this time. So we end up with our bundled expat compiled using namespacing and so defining symbols like PyExpat_XML_SetCommentHandler while pyexpat.c is looking for XML_SetCommentHandler because it is compiled *not* using our bundled expat.h. I am not sure yet why your custom "-I" comes before "-I/ae/data/soft/opensource/build/python3/master/Python-3.4.0/Modules/expat" as it certainly should not. So far I tried building with CPPFLAGS and CFLAGS and in both cases my custom paths come after "-I.../Modules/expat" as it should. Can you please provide your ./configure and make command lines and relevant environment variables? Thanks, Lucas
Actually CFLAGS do indeed come before any include directories. I can reproduce your problem: mkdir /tmp/extra_include cp /usr/include/expat.h /usr/include/expat_external.h /tmp/extra_include/ make CFLAGS="-I/tmp/extra_include" You should use CPPFLAGS for extra include directories. Not an issue in CPython.
