Bugs item #1437785, was opened at 2006-02-23 15:59
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&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: XML
Group: Python 2.4
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems w/ expat 1.95.7 vs. Python 2.4
Initial Comment:
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?
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2006-08-12 19:20
Message:
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).
----------------------------------------------------------------------
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-29 03:41
Message:
Logged In: YES
user_id=849994
Should be fixed by patch #1295808.
----------------------------------------------------------------------
Comment By: Skip Montanaro (montanaro)
Date: 2006-03-03 12:15
Message:
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.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2006-03-03 09:44
Message:
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?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
