RetroSearch Browse

Tue Nov 23 05:56:46 CET 2004 · https://mail.python.org/pipermail/python-dev/2004-November/050086.html

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, 
>> the
>> user gave gcc a -m32 flag.  How would that be reflected in the 
>> environment?
>
> 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"
> #else
> #error Unable to detect architecture word length
> #endif
>
> This way, if the compiler is in 32-bit mode, the proper file is 
> included.

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.

James

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-November/050086.html below:

[Python-Dev] Multilib strikes back