Re: Compiling python extension on amd64 for 32 bit

2007-05-26 Thread Andrew MacIntyre
Mathias Waack wrote:
> Andrew MacIntyre wrote:
> 
>> Mathias Waack wrote:
>>> After switching my development environment to 64 bit I've got a
>>> problem with a python extension for a 32 bit application.
>> {...}
>>
>>> Ok, thats fine. So why is python complaining? Or even more
>>> interesting, what do I have to do to compile the code?
>> Is the Python your toolchain is referencing 32 or 64 bit?  Based on
>> what I can see in pyport.h, I'd guess that you're finding a 64 bit
>> Python (ie SIZEOF_LONG == 8).
> 
> There is no such thing as "the Python". A biarch environment offers
> both the 32 bit and the 64 bit versions of each library. And unique
> headers, because its assumed that the headers are independent of the
> architecture. Because of the -m32 Flag the pyport.h is used within a
> 32 bit env. 

Every Python installation has an architecture dependent header
(pyconfig.h), unless a vendor specifically creates a replacement which
neutralises this; that header contains the definition (SIZEOF_LONG) that
triggers your problem.

-- 
-
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: [EMAIL PROTECTED]  (pref) | Snail: PO Box 370
[EMAIL PROTECTED] (alt) |Belconnen ACT 2616
Web:http://www.andymac.org/   |Australia
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Compiling python extension on amd64 for 32 bit

2007-05-26 Thread Mathias Waack
Andrew MacIntyre wrote:

> Mathias Waack wrote:
>> After switching my development environment to 64 bit I've got a
>> problem with a python extension for a 32 bit application.
> 
> {...}
> 
>> Ok, thats fine. So why is python complaining? Or even more
>> interesting, what do I have to do to compile the code?
> 
> Is the Python your toolchain is referencing 32 or 64 bit?  Based on
> what I can see in pyport.h, I'd guess that you're finding a 64 bit
> Python (ie SIZEOF_LONG == 8).

There is no such thing as "the Python". A biarch environment offers
both the 32 bit and the 64 bit versions of each library. And unique
headers, because its assumed that the headers are independent of the
architecture. Because of the -m32 Flag the pyport.h is used within a
32 bit env. 

Mathias
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Compiling python extension on amd64 for 32 bit

2007-05-25 Thread Andrew MacIntyre
Mathias Waack wrote:
> After switching my development environment to 64 bit I've got a problem with
> a python extension for a 32 bit application.

{...}

> Ok, thats fine. So why is python complaining? Or even more interesting, what
> do I have to do to compile the code?

Is the Python your toolchain is referencing 32 or 64 bit?  Based on what
I can see in pyport.h, I'd guess that you're finding a 64 bit Python (ie
SIZEOF_LONG == 8).

-- 
-
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: [EMAIL PROTECTED]  (pref) | Snail: PO Box 370
[EMAIL PROTECTED] (alt) |Belconnen ACT 2616
Web:http://www.andymac.org/   |Australia
-- 
http://mail.python.org/mailman/listinfo/python-list


Compiling python extension on amd64 for 32 bit

2007-05-25 Thread Mathias Waack
After switching my development environment to 64 bit I've got a problem with
a python extension for a 32 bit application. Compiling the app under Linux
results in the following error:

g++ -m32 -Wall -g -O2  -I. -Idb -DPYTHON=25 -o mappy.o -c mappy.cpp
In file included from /usr/include/python2.5/Python.h:57,
 from mappy.cpp:29:
/usr/include/python2.5/pyport.h:732:2: error: #error "LONG_BIT definition
appears wrong for platform (bad gcc/glibc config?)."

My gcc is:

Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr 
--with-local-prefix=/usr/local --infodir=/usr/share/info 
--mandir=/usr/share/man 
--libdir=/usr/lib64 --libexecdir=/usr/lib64 
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada 
--enable-checking=release 
--with-gxx-include-dir=/usr/include/c++/4.1.2 
--enable-ssp --disable-libssp 
--disable-libgcj --with-slibdir=/lib64 
--with-system-zlib --enable-shared --enable-__cxa_atexit 
--enable-libstdcxx-allocator=new --program-suffix=-4.1 
--enable-version-specific-runtime-libs --without-system-libunwind 
--with-cpu=generic 
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)

So I've checked this magic LONG_BIT define: 

#:/tmp cat t.c
#include 
#include 

int main()
{
  printf("%d\n",sizeof(long));
  printf("%d\n",LONG_BIT);
  return 0;
}
#:/tmp gcc t.c
#:/tmp ./a.out
8
64
#:/tmp gcc -m32 t.c
#:/tmp ./a.out
4
32

Ok, thats fine. So why is python complaining? Or even more interesting, what
do I have to do to compile the code?

Mathias
-- 
http://mail.python.org/mailman/listinfo/python-list