Re: Dealing with segfaults in lxml?

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