[lxml-dev] Dealing with segfaults in lxml?

[Steve Lianoglou]

> On OS X, you might actually be using the system libs rather than  
> the newer
> libs (in /opt/local/lib, if you are using MacOSPorts, for  
> example).  I had
> lots of segfault problems until I realized that even though lxml was
> claiming it was running with the newer libs, the info was only  
> based on what
> it was built with.  At least, that's what it seemed like.
>
> Anyway, all my (segfault) problems went away when I exported
>
> DYLD_LIBRARY_PATH=/opt/local/lib
>
> Into the environment where python was running.

Hmm .. interesting.

I was playing with DYLD_LIBRARY_PATH, but I thought that had to be  
set during compile time (of lxml).

Even though ... through my hunting on the intarweb, I came across a  
suggestion to use `otool` to see what libs were being used. So I  
tried like so:

$ otool -L /opt/local/Library/Frameworks/Python.framework/Versions/ 
Current/lib/python2.4/site-packages/lxml/etree.so
/opt/local/Library/Frameworks/Python.framework/Versions/Current/lib/ 
python2.4/site-packages/lxml/etree.so:
         /opt/local/lib/libxslt.1.dylib (compatibility version 3.0.0,  
current version 3.22.0)
         /opt/local/lib/libexslt.0.dylib (compatibility version  
9.0.0, current version 9.13.0)
         /opt/local/lib/libxml2.2.dylib (compatibility version 9.0.0,  
current version 9.30.0)
         /opt/local/lib/libz.1.dylib (compatibility version 1.0.0,  
current version 1.2.3)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 88.3.9)

The fact that the xml libs in /opt/local were the ones being  
referenced made me think that those are the ones it would use ... is  
that right? Looking at that closer, I do see ``/usr/lib/ 
libSystem.B.dylib``which is OS X default, but honestly don't know  
what it's responsible for ...

-steve