On the platforms that can run both 32 and 64bit python, such as x86_64, distutils builds both 32 and 64 bit libraries in the same directory such as build/lib.linux-x86_64-2.5. This can be easily fixed by placing 64 bit libraries in build/lib64.linux-x86_64-2.5 instead. On the other hand it may be time to revisit use of os.uname in distutils' get_platform to determine the target directory. In the environments that can run python interpreters compiled for different architectures, distutils' get_platform should return the platform for which the interpreter was built, not the platform on which it runs. Similar problem exists with the default install directory $prefix/lib/python2.5/lib-dynload. 64-bit libraries should probably go to $prefix/lib/python2.5/lib64-dynload instead. I've noticed that there was a similar proposal to use $prefix/lib64 for 64bit binary components, but it was quickly rejected: http://mail.python.org/pipermail/python-dev/2006-November/070044.html In my view, following LSB spirit would suggest splitting pythonX.Y tree into platform dependent part (*.so) that would go under $prefix/lib or $prefix/lib64 and a platform independent part (*.py{,c,o}) that would go under $prefix/share. This, of course, would be a much bigger change than the lib64-dynload band aid that I am proposing here. PS: As a data point, the R project has made the following changes to their program to deal with this issue: """ o LDFLAGS now defaults to -L/usr/local/lib64 on most Linux 64-bit OSes (but not ia64). The use of lib/lib64 can be overridden by the new variable LIBnn. o The default installation directory is now ${prefix}/${LIBnn}/R, /usr/local/lib64/R on most 64-bit Linux OSes and /usr/local/lib/R elsewhere. """ <https://stat.ethz.ch/pipermail/r-announce/2005/000802.html>