[Python-Dev] distutils mixes 32/64bit binaries

[Alexander Belopolsky]

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>