Matteo Franchin's corner

Python 2.7.2 compiled without zlib module with Ubuntu 11.10 or 11.04

The problem and the solution

Python 2.7.2 fails to compile properly on Ubuntu 11.04 or 11.10. In particular, libz.so is not found and this has some inconvenient consequences: the zlib module is not built due to this; other modules fail to compile; setuptools cannot be installed, etc. The quick solution: just install the package dpkg-dev before configuring and compiling Python. This works well for Python 2.7.2 and Ubuntu 11.10.

Why?

The problem is the result of a recent change in Ubuntu and the deficiency of the configuration system of Python (as far as I can see).

Recent versions of Ubuntu (starting from 11.04) have introduced the so-called multiarch (see https://wiki.ubuntu.com/MultiarchSpec). libz.so and some other libraries are now located in directories like /usr/lib/x86_64-linux-gnu/ (the actual directory name may change from system to system) rather than simply /usr/lib.

This shouldn’t be a problem. Once zlib1g-dev is installed, your C compiler can correctly find the zlib headers. The linker is also multiarch-aware and can find zlib without problems, at least once the right flag -lz has been given to it. Why does Python fail, then? The reason is that Python tries to locate the file libz.so by itself, rather than testing whether the linker can actlually find and use the zlib library. You can see this by inspecting the file setup.py at the top of the Python directory tree (as obtained from the tarball). If you search for multiarch in the same file, however, you can actually see that Python has some support for multiarch directory scheme. What it does is to see whether the executable dpkg-architecture is installed on the system. If this is the case, then it tries to use it to determine the name of the directory containing the multiarch libraries. If not, then it just gives up. This is why you need to install the dpkg-dev package. This package contains the executable dpkg-architecture which enables Python to automatically determine the directory where libz.so is.

This, to me, looks as a bug (or deficiency) of the Python build system. But one never knows (there may be other underlying reasons why Python wants to find the library explicitly, rather than leaving this to the linker).