Introduction
Recently I upgraded to OS X Lion and here are my notes on how I got my working environment working.
XCode
First things first, you need to setup build tools (gcc, make and the like). On OS X these come as a part of XCode. Even if you had XCode installed on Snow Leaopard before upgrading to Lion, do take time and reinstall it completely. Stuff changed since the white cat and it’s safer to have your build tools up-to-date.
collective.buildout.python
Same story as with XCode. Remove your collective.buildout.python directory entirely and recreate it from scrach. It takes a while, go make yourself some nice tea.
UPDATE: In OSX 10.7.1 readline does not get built because it’s configuration script does not correctly recognizes the OS. You can fix this by appending the following two lines to the bottom of src/readline.cfg in your local checkout of collective.buildout.python and re-running buildout.
make-options =
SHOBJ_LDFLAGS="-dynamiclib"
egg cache
If you are using a local egg cache it might get tricky. Some people report everything works fine, but several people also report that things were randomly breaking until they had removed all eggs from their egg cache and re-ran buildout. My suggestion? Clear the cache! It takes a while to download all those eggs again, but it beats losing a day chasing readline related SEGFAULTS causing Zope crashes on seemingly random requests:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x00000001131ccf09 in call_readline ()
lxml
If you are using z3c.recipe.staticlxml you are in more trouble. The latest version uses libxml2-2.6.32 and libxslt-1.1.24 and these two break in a very nasty way when you try to access a Plone site themed with Diazo. Zope crashes with no traceback. Attaching gdb to the process spits out the following error:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000001400001c4f [Switching to process 89119] 0x00007fff8dbcd403 in strncmp () (gdb) bt #0 0x00007fff8dbcd403 in strncmp () #1 0x00000001088e5830 in __xmlParserInputBufferCreateFilename (URI=0x1400001c4f <Address 0x1400001c4f out of bounds>, enc=163580032) at xmlIO.c:2412 #2 0x00000001088bc951 in xmlNewInputFromFile (ctxt=0x10985e5b0, filename=0x10407fd30 "/Users/zupo/work/example.project/eggs/diazo-1.0rc3-py2.6.egg/diazo/defaults.xsl") at parserInternals.c:1462 [...snip...]
One solution is to add the following two lines to the [lxml] part of your buildout.cfg:
libxml2-url = ftp://xmlsoft.org/libxml2/libxml2-2.7.8.tar.gz libxslt-url = ftp://xmlsoft.org/libxml2/libxslt-1.1.26.tar.gz
These tell lxml to build against newer versions of libxml2 and libxslt making those nasty errors go away.
UPDATE: You can just as well use the latest version of z3c.recipe.staticxml which includes URLs to newer versions of both libxml2 and libxslt.
The other solution is simply to not use z3c.recipe.staticlxml at all. It seems that you can now use your system’s libxml provided to you by XCode (located at /usr/include/libxml2). To do this, remove [lxml] from your buildout.cfg and re-run buildout.
