As per summary, there's an internal copy of expat 1.x in pyexpat shared object, and its symbols are not hidden either. Loading in the same process space both libexpat (2) and python with pyexpat will likely cause crashes not so easy to debug. Easy solution: hide the symbols. Proper solution: use the already-installed shared copy of libexpat.
Created attachment 120136 [details, diff] celementtree-1.0.5-external-libexpat.patch This patch replaces the bundled sources with a link to libexpat. This mostly work, where mostly is one of the tests expects to receive 1.95.8 as output for the expat version but instead gets 2.0.0; it doesn't seem to be fatal.
the fix in CVS. I've also modified the test so it won't check for expat's version. thanks for reporting ;)
2.5.2 has two copies of it, one in pyexpat and one in celementtree.
This¹ patch should fix it. It will be included in the next revision bump. alip@trippin> ldd /usr/lib64/python2.5/lib-dynload/{pyexpat,_elementtree}.so |grep libexpat ~/src/gentoo-x86/dev-lang/python libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f53e8be0000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007ff1ad7b8000) Looks fine :) ¹: http://overlays.gentoo.org/proj/python/changeset/60
2.5.2-r3 includes this. Thanks for reporting :)
