Issue 1158926: Names conflict with QT (on linux) (original) (raw)

Created on 2005-03-08 10:07 by cyberran, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (6)

msg47886 - (view)

Author: CyberRan (cyberran)

Date: 2005-03-08 10:07

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

msg47887 - (view)

Author: Martin v. Löwis (loewis) * (Python committer)

Date: 2005-03-08 12:19

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.

msg47888 - (view)

Author: CyberRan (cyberran)

Date: 2005-03-09 09:13

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

msg47889 - (view)

Author: Martin v. Löwis (loewis) * (Python committer)

Date: 2005-03-09 23:07

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.

msg47890 - (view)

Author: CyberRan (cyberran)

Date: 2005-03-10 09:12

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.

msg47891 - (view)

Author: Martin v. Löwis (loewis) * (Python committer)

Date: 2007-03-05 13:40

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.