Re: Compiling python extension on amd64 for 32 bit
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
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
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
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