[Python-Dev] Multilib strikes back
James Y Knight
foom at fuhm.net
Tue Nov 23 05:56:46 CET 2004
On Nov 22, 2004, at 9:19 PM, Mihai Ibanescu wrote:
> On Mon, Nov 22, 2004 at 02:01:24PM -0600, Skip Montanaro wrote:
>> Mihai> How about a _pyconfig_32.h and a _pyconfig_64.h and have
>> Mihai> pyconfig.h include one or the other, depending on the
>> Mihai> environment?
>> How would that be detected? As I understand the original bug report,
>> user gave gcc a -m32 flag. How would that be reflected in the
> With the help of Jakub: pyconfig.h would have something close to:
> #include <limits.h>
> #if CHAR_BIT == 8 && LONG_MAX == 0x7fffffff
> #include "_pyconfig_32.h"
> #elif CHAR_BIT == 8 && LONG_MAX == 0x7fffffffffffffff
> #include "_pyconfig_64.h"
> #error Unable to detect architecture word length
> This way, if the compiler is in 32-bit mode, the proper file is
I think that is the wrong solution. The right solution is to put
pyconfig.h in an arch-specific directory. In current standards, that'd
probably have to be /usr/lib*: e.g. /usr/lib/python2.4/include/ and
/usr/lib64/python2.4/include/. In the proposed multiarch standard
(http://www.linuxbase.org/~taggart/multiarch.html), that would be
/usr/include/i386-linux/ and /usr/include/x86_64-linux/.
Different, but slightly related: since .py files aren't platform
dependent, /usr/lib* is really the wrong place for them. They should be
going in /usr/share/python2.X/ not /usr/lib*/python2.X/. Obviously the
.so files still need to go in /usr/lib*, though, so that might be a bit
of a trick.
More information about the Python-Dev