Patches item #1158926, was opened at 2005-03-08 11:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1158926&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: CyberRan (cyberran) Assigned to: Nobody/Anonymous (nobody) Summary: Names conflict with QT (on linux) Initial Comment: 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. [EMAIL PROTECTED] ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-05 14:40 Message: Logged In: YES user_id=21627 Originator: NO 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. ---------------------------------------------------------------------- Comment By: CyberRan (cyberran) Date: 2005-03-10 10:12 Message: 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. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2005-03-10 00:07 Message: 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. ---------------------------------------------------------------------- Comment By: CyberRan (cyberran) Date: 2005-03-09 10:13 Message: 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 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2005-03-08 13:19 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1158926&group_id=5470 _______________________________________________ Patches mailing list [email protected] http://mail.python.org/mailman/listinfo/patches
