[lxml-dev] install lxml 2.0.5 on Mac OS X Leopard - why is it so hard?

[Kumar McMillan]

I know this has been discussed over and over but I'm writing to see if
anyone has made a breakthrough yet.  The problem of course is that
Leopard's builtin libxml2 and libxslt are too old for lxml 2.0.  You
have to build libxml2 either from source or use a port.  There is
currently a problem with the libxml2 port, but the workaround is going
fine for me: http://trac.macports.org/ticket/15230 (I know because
postgres built just fine and I have some tests exerising psycopg2 as
well)

So after updating my libxml2 to 2.6.31 and libxslt to 1.1.23 and
updating my $PATH so that the new xml2-config and xslt-config can be
found, I can build lxml *without errors* but I see these warnings:

$ sudo easy_install lxml-2.0.5.tgz
Processing lxml-2.0.5.tgz
Running lxml-2.0.5/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-3azY8e/lxml-2.0.5/egg-dist-tmp-t80esG
Building lxml version 2.0.5.
NOTE: Trying to build without Cython, pre-generated 'src/lxml/etree.c'
needs to be available.
Using build configuration of libxslt 1.1.23

ld: warning in /opt/local/lib/libxslt.dylib, file is not of required
architecture
ld: warning in /opt/local/lib/libexslt.dylib, file is not of required
architecture
ld: warning in /opt/local/lib/libxml2.dylib, file is not of required
architecture
[... and more like this ...]
...
Finished processing dependencies for lxml==2.0.5


What doesn't make sense is these files seem fine to me:

$ file -L /opt/local/lib/libxslt.dylib
/opt/local/lib/libxslt.dylib: Mach-O dynamically linked shared library i386
$ file -L /opt/local/lib/libexslt.dylib
/opt/local/lib/libexslt.dylib: Mach-O dynamically linked shared library i386


I was having similar trouble like this on Tiger and I had test cases
in my own test suite that would consistently segfault.  On Leopard,
those same test cases were *not* segfaulting but now I have some
different test cases that are consistently segfaulting.  The segfault
looks like this in the crash log:

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000008
Crashed Thread:  0

Thread 0 Crashed:
0   libxml2.2.dylib                     0x90d39419 xmlDictLookup + 360
1   libxml2.2.dylib                     0x025626e4 xmlXPathCompExprAdd + 212
2   libxml2.2.dylib                     0x025709c6 xmlXPathCompPathExpr + 3910
[etc....]

Setting my dyld path (like suggested in the docs, export
DYLD_LIBRARY_PATH=/opt/local/lib:/usr/lib) *does* make my test cases
run without segfault so I'm assuming what's happening is lxml is using
the older dylibs at runtime.  This is a really lame way to fix the
problem!  Specifically, my svn binaries do not like this dylib
setting, producing errors like:

$ svn ls
dyld: lazy symbol binding failed: Symbol not found: _iconv_open
  Referenced from: /usr/lib/libaprutil-1.0.dylib
  Expected in: /opt/local/lib/libiconv.2.dylib
[etc]

(This is slightly odd since I included /usr/lib but whatever.)

*sigh*  Next, I tried doing a static build of lxml by setting
STATIC_LIBRARY_DIRS = ['/opt/local/lib'] in setup.py and running:

python setup.py bdist_egg --static
--with-xml2-config=/opt/local/bin/xml2-config
--with-xslt-config=/opt/local/bin/xslt-config

I had to fiddle with gcc to get this to build but otherwise it built
fine and installed ok but I did not see any difference.  Still
consistent segfaults that are fixed by setting the dyld path.


Now I'm out of ideas.  Does anyone have another suggestion?  Until
then I have a stupid bash file that I have to source anytime I want to
work on lxml.


-Kumar