CentOS’s repos don’t have a working version of libxslt (you need 1.1.20, repos have 1.1.17) so we need to statically compile it for collective.xdv to work.
But, there is a catch! You need to be careful about how you order your parts in your buildout.cfg.
For examle, the following buildout.cfg works perfectly fine, it downloads libxml and libxslt and compiles them in your buildout environment for your use:
[buildout] extends = http://dist.plone.org/release/4.0/versions.cfg parts = lxml zopepy [zopepy] recipe = zc.recipe.egg interpreter = zopepy eggs = lxml [lxml] recipe = z3c.recipe.staticlxml egg = lxml static-build = true
Problems start when you change the order of ‘parts’ section to be like this:
[buildout] parts = zopepy lxml ...
In this case, zopepy wants to fetch the lxml egg and compile lxml immediately. Since the ‘lxml’ part has not been run yet, there is no libxml2 and libxslt available in your buildout and the whole thing crashes. The point being: always put the lxml part at the top of your parts list.
The fix is a one-liner and I just spent 2 days figuring it out. I wish I knew this earlier.
UPDATE: Florian Schulze pointed out that “an even better fix is to reference the lxml part from zopepy.
[buildout]
extends = http://dist.plone.org/release/4.0/versions.cfg
parts =
lxml
zopepy
[zopepy]
recipe = zc.recipe.egg
interpreter = zopepy
eggs =
${lxml:egg}
[lxml]
recipe = z3c.recipe.staticlxml
egg = lxml
static-build = true
That way buildout always installs the lxml part first, because it installs a part before resolving any references to it. This way you actually only need zopepy in parts and can leave out lxml completely.”
