The patch fixes a problem when embedding python 2.4
(using static library) in an application that also link
against qt 3.3 (using the qt-mt shared library). 

If an XML import is used in an application containning
the QT library, a strange segmentation fault occoured.
After reasearching this problem, I found out that there
is a name conflict for a symbol exported by the QT
library and the pyexpat module SO file. 

The symbol name is "XML_ErrorString". The cause for
this problem is the fact that the symbol is not defined
static in the pyexpat module (it is used in several
different compilation units).

The solution is to simply replace the "XML_ErrorString"
symbol with "PyXML_ErrorString".

Ran.

ran.peleg@gmail.com

Logged In: YES 
user_id=21627

I can't understand why this happened. What precisely was a
static library in your application, if both qt-mt and the
expat extension where shared libraries? Also, why does qt-mt
export XML_ErrorString? In my copy of qt-mt, it does not;
instead, it links with expat.so.1.

Unless you have modified something, the Python extension
module should have been loaded with RTLD_LOCAL, which should
have preferred its own definition of XML_ErrorString over
the one in Qt.

I'm hesitant to apply the patch, because:
a) these are original Expat sources, not Python sources, and
we prefer to use them unmodified (or else a future import of
expat will just undo this change),
b) renaming a single function does no good - if the problem
can occur with this function, it can occur with any other
function,
c) even in your application, I wonder why renaming
XML_ErrorString solved the problem. If you really somehow
got an entire copy of Expat into your qt-mt, and if you
really somehow managed to make pyexpat find parts of Expat
in qt-mt, this problem should have occurred with any other
of the qt symbols as well.

Logged In: YES 
user_id=1229149

The static library was the python library (libpython2.4.a)
itself. After further investigating this problem I have
found out that the qt-mt library is using the expat shared
library (libexpat.so). The XML_ErrorString symbol name
contention is between this library and the pyexpat.so module.

Ran

Logged In: YES 
user_id=21627

Can you please post a small test case (C file + Makefile,
e.g. for Linux, perhaps + Python file) demonstrating your
problem? I still have a hard time believing your analysis of
the problem, and believing that your proposed solution is
correct.

Logged In: YES 
user_id=1229149

Here is a minimal test that shows the problem. I have tested
this on two different systems (32Bit system running Fedore
core 2 and on 64Bit system running Fedora core 3).

You may have to change some paths in the "build.sh" file
according to your system configuration.

Ran.

Thanks for the patch. This was later resubmitted and applied as #1295808, so I believe the problem is fixed, and this patch out-of-date.