This may apply to the trunk as well... Today I finished installing 2.4.2 and all our local libraries at work. Trying out the main application I use I discovered Python segfaulting when trying to import pyexpat. It turned out that during the import an earlier module (gtk.glade) also wanted libexpat. Apparently pyexpat was expecting to get Expat 1.95.8 (what's delivered with Python) but got 1.95.7 instead (what we had installed and what was already linked with all our other Expat-using code). The solution was rather simple. I just commented out those constants in the pyexpat initialization that were marked as 1.95.8. Fortunately there was a comment identifying the version dependency. Is there some way that Python's build process can detect the Expat version and conditionally include/exclude bits that are for later versions?
Logged In: YES user_id=21627 I don't understand the problem. The build process should have picked-up the Python-provided expat, and should have ignored the system-installed one in all places (compiling, linking, running). What was the specific sequence of commands that you entered, what what the output you got, and what output would you have expected instead?
Logged In: YES user_id=44345 Martin, I'm sorry. If I understood it better I'd explain it better. Tell me if this helps. We have expat 1.95.7 installed. We have C++ libraries that link with that version and are wrapped for use with Python using SWIG. Python 2.4 comes with 1.95.8. Apparently setup.py finds that and compiles pyexpat against it. In the pyexpat init function I see this block of constant initialization: /* Added in Expat 1.95.8. */ MYCONST(XML_ERROR_UNDECLARING_PREFIX); MYCONST(XML_ERROR_INCOMPLETE_PE); MYCONST(XML_ERROR_XML_DECL); MYCONST(XML_ERROR_TEXT_DECL); MYCONST(XML_ERROR_PUBLICID); MYCONST(XML_ERROR_SUSPENDED); MYCONST(XML_ERROR_NOT_SUSPENDED); MYCONST(XML_ERROR_ABORTED); MYCONST(XML_ERROR_FINISHED); MYCONST(XML_ERROR_SUSPEND_PE); If they are left in there, Python reliably segfaults at the first of those lines. When I exclude those lines, everything works fine. If I run ldd over pyexpat.so I don't see that libexpat is dynamically linked in: % ldd pyexpat.so libgcc_s.so.1 => /opt/lang/gcc-3.3.2/lib/libgcc_s.so.1 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 I thus have a statically linked version of libexpat 1.95.8 which appears to be exporting symbols: % nm -p pyexpat.so | egrep XML 0000042312 T XML_DefaultCurrent 0000042380 T XML_ErrorString 0000042428 T XML_ExpatVersion 0000042452 T XML_ExpatVersionInfo 0000039164 T XML_ExternalEntityParserCreate 0000042232 T XML_FreeContentModel 0000040580 T XML_GetBase 0000041584 T XML_GetBuffer ... Elsewhere I have a C++ library that is dynamically linked to 1.95.7, so I essentially have libexpat linked into the system twice. Does that seem like a reasonable description of our setup? If so, I can understand that trying to use (for example) XML_ERROR_UNDECLARING_PREFIX (which is new to 1.95.8) with symbols from libexpat 1.95.7 might create problems. I don't see how it could cause problems during constant initialization, but it does, quite reliably. You're much more savvy about these things than I am. Maybe you can see how this would happen. How do we tell Python's build process not to use the bundled 1.95.8? My local C++ gurus tell me they are not willing to rebuild everything with 1.95.8 just to make pyexpat happy. If we tell it that, then those constant initialization lines need to be conditionally exposed to the compiler so that it works to compile with libexpat 1.95.7.
Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).
