Tag Archives: CentOS

Assertion `t_size >= b_size’ failed

Recently, when migrating a Plone 4 site from one VPS server instance to another, we had the following problem:

We were not able to start Zope with Supervisord because it crashed every time we tried to start it. Running Zope in foreground (bin/instance fg) produced the following error:

Python: Objects/typeobject.c:1736: extra_ivars: Assertion `t_size >= b_size' failed.
Aborted

Luckily, after some Googling around I discovered that Hanno had already commited a patch to fix this. Pinning eggs to patched versions by adding the lines below to versions.cfg fixed the problem entirely.

# Handle tp_basicsize correctly
ExtensionClass = 2.13.2
Persistence = 2.13.2

Deploying Cyn.in 3.1.3 on CentOS 5.4

Last week we were upgrading Cyn.in to the latest version. After a few days of testing on a local server it was time to deploy it to the server.

Since Cyn.in needs quite some RAM to operate normally, we chose Virpus VPS instance with 2 gigs of RAM, running CentOS 5.4.

Running buildout on the server produced this error:

...
Modules/constants.c: In function ‘LDAPinit_constants’:
Modules/constants.c:184: error: ‘LDAP_OPT_X_TLS_NEWCTX’ undeclared (first use in this function)
Modules/constants.c:184: error: (Each undeclared identifier is reported only once
Modules/constants.c:184: error: for each function it appears in.)

After a bit of googling around it seemed that the problem was caused by a bug in python-ldap. A quick look at CHANGES revealed that 2.3.10 version of python-ldap mentions work being done around LDAP_OPT_X_TLS_NEWCTX. Maybe it was fixed in the next version, 2.3.11?

I tried pinning the version of python-ldap to 2.3.11 and buildout finished without errors. Great!

Adding the following lines to buildout.cfg makes buildout more repeatable and future-proof:

versions = versions

[versions]
python-ldap = 2.3.11

Order of ‘parts’ when compiling lxml

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.”

Compiling lxml on 64bit CentOS

A few days ago I encountered a problem while deploying Plone 4 with collective.xdv to a CentOS cloud instance. Since CentOS’ repos were a bit out of date I needed to statically compile lxml and it’s dependencies with z3c.recipe.staticlxml. Here’s what you need to add to your buildout.cfg to do so:

parts += lxml
eggs += lxml

# ===================================================================
# For collective.xdv to work properly, we need a static build of lxml
# and it's dependencies on OS X and x86_64 Linux                     
# ===================================================================
[lxml]
recipe = z3c.recipe.staticlxml
egg = lxml
force = false
static-build = true

And here’s the kicker: on some 64-bit Linux systems compiling lxml produces an error like this at compile-time:

lxml: Building lxml ...
Building lxml version 2.2.6.
NOTE: Trying to build without Cython, pre-generated 'src/lxml/lxml.etree.c' needs to be available.
Using build configuration of libxslt 1.1.24
Building against libxml2/libxslt in one of the following directories:
  /home/production/1.1/parts/lxml/libxslt/lib
  /home/production/1.1/parts/lxml/libxml2/lib
/usr/bin/ld: /home/production/1.1/parts/lxml/libxslt/lib/libxslt.a(xslt.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/home/production/1.1/parts/lxml/libxslt/lib/libxslt.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error: Setup script exited with error: command 'gcc' failed with exit status 1
An error occured when trying to install lxml 2.2.6. Look above this message for any errors that were output by easy_install.
While:
  Updating lxml.
Error: Couldn't install: lxml 2.2.6

Some problem with -fPIC flag not being set or something? After googling around without much success I decided to take a look directly in trunk of z3c.recipe.staticlxml and luckily Reinout had the same problem before me and already committed a patch. So all that was needed was to pull z3c.recipe.staticlxml from trunk and the compile error went away.

UPDATE: I emailed Stephan Eletzhofer to make a new release of z3c.recipe.staticxml that would include Reinout’s patch. He responded quickly and now all you need to do is make sure you have z3x.recipe.staticxml of version of 0.7.2 or higher:

[versions]
# we need this so that -fPIC flag is set when compiling lxml on 64 bit Linux
z3c.recipe.staticlxml = 0.7.2