4 Oct 2007 04:06
Re: Dealing with segfaults in lxml?
Eric Tiffany <etiffany <at> alum.mit.edu>
2007-10-04 02:06:11 GMT
2007-10-04 02:06:11 GMT
Check the man page for dyld, which notes DYLD_LIBRARY_PATH This is a colon separated list of directories that contain libraries. The dynamic linker searches these directories before it searches the default locations for libraries. It allows you to test new versions of existing libraries. For each library that a program uses, the dynamic linker looks for it in each directory in DYLD_LIBRARY_PATH in turn. If it still can't find the library, it then searches DYLD_FALL- BACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH in turn. Use the -L option to otool(1). to discover the frameworks and shared libraries that the executable is linked against. I think otool is telling you what libs the .so would *like* to use, but the environment will tell dyld where to look at runtime. At least, that's the way I interpret it. Anyway, my segfaults and bus errors stopped. ET On 10/3/07 7:50 PM, "Steve Lianoglou" <lists.steve <at> arachnedesign.net> wrote: >> 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 -- -- ____________________________________________________ Eric Tiffany | eric <at> projectliberty.org Interop Tech Lead | +1 413-458-3743 Liberty Alliance | +1 413-627-1778 mobile