I'm among the multitudes of osx users that wasted loads of time getting lxml to run. The last quote I saw is from Eric Steele : Unfortunately, I wound up wasting half a day trying to fix a broken install of lxml on OSX, before giving up and creating a new Ubuntu VM through Parallels.
There are a couple of buildout recipes for static compilation of lxml. Not one, but several. And lxml itself also has some --yeah-bloody-well-fully-static compile option. Not one of them worked for me. When my zope crashed, I got an OSX crash dialog. When inspecting the more-or-less traceback, I noticed that most of the lxml-related items appeared to come from the statically compiled version, apart from calls to libgcry_. That's part of libgcript, a general purpose cryptographic library. I assume it is used for signing pdfs or so when generated from xslt or something non-zope-related like that.
Solution in my particular case: deactivate libgcrypt in macports... I've seen libgcrypt working perfectly with lxml on someone else's laptop, so it is not a sure-fire way for sure.
IF your python or zope crashes with an osx crash dialog, you can be sure there's some linked C library that is crying abuse. I still have no actual clue why removing libgcrypt made a static lxml more static (yes, I needed to recompile first), but anyway... Perhaps this helps someone in figuring out his weird error combination...
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):
But it was still the removal of libgcrypt that made it all work for me. And I got a confirmation in irc of someone who was also baffled by a non-working static lxml: for him, too, removing libgcrypt resolved the issue.