homepage

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.