Cross compiling (i386 from amd64) with distutils

J

Jason

My situation is this: I have a Diamond Systems single-board computer
with a
matching GPIO board. DS have a library for controlling the GPIO
board... but
it's a static library (libdscud-6.02.a) with an accompanying header
(dscud.h).
I'd like to create a Python extension to use the device.

The architecture of the SBC is 486, and it runs Debian Squeeze/Grip.
While it
is possible to develop on it directly, I'd rather use my desktop
machine
(Debian Squeeze, amd64).

If I write a simple C program to control the device, I'd include the
header
file and cross-compile it like so:

gcc -m32 -march=i386 -lpthread -I/usr/local/dscud-6.02 -o dio
dio.c \
/usr/local/dscud-6.02/libdscud-6.02.a

To get myself started with the Python extension, I've basically taken
the
"noddy" demo[1] and thrown in a function call from the DSC library
just to see
if I can get something to build.

My distutils setup.py looks like:

----
from distutils.core import setup, Extension

module1 = Extension('noddy',
sources = ['src/noddy.c'],
libraries = ['pthread'],
include_dirs = ['/usr/local/dscud-6.02'],
extra_objects = ['/usr/local/dscud-6.02/libdscud-6.02.a'],
extra_compile_args = ['-m32', '-march=i386'])

setup(name = 'Noddy', version = '1.0', description = 'This is a demo
package',
ext_modules = [module1])
----

This works fine on the target machine with "python setup.py build",
but when I
try it on my desktop machine, I get:

----
$ python setup.py build
running build
running build_ext
building 'noddy' extension
creating build
creating build/temp.linux-x86_64-2.6
creating build/temp.linux-x86_64-2.6/src
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -I/usr/local/dscud-6.02 -I/usr/include/
python2.6 -c
src/noddy.c -o build/temp.linux-x86_64-2.6/src/noddy.o -m32 -
march=i386
In file included from /usr/include/python2.6/Python.h:58,
from src/noddy.c:1:
/usr/include/python2.6/pyport.h:694:2: error: #error "LONG_BIT
definition
appears wrong for platform (bad gcc/glibc config?)."
error: command 'gcc' failed with exit status 1

----

So is it possible to get distutils to cross compile something like
this, and
if so, what am I missing? Or am I using the wrong tool for the job?

Target python ver. is 2.6. GCC is 4.4.5.

Cheers,
Jason

[1] http://docs.python.org/extending/newtypes.html
 
M

Martin v. Loewis

So is it possible to get distutils to cross compile something like
this, and
if so, what am I missing? Or am I using the wrong tool for the job?

At a minimum, you should be using the target's python binary. distutils
has close-to-none cross-compiling support. You can solve some of the
problems by editing the Makefile which it uses to learn the compiler
options from.

Regards,
Martin
 
J

Jason

At a minimum, you should be using the target's python binary. distutils
has close-to-none cross-compiling support.

Do you know if virtualenv allows installing a Python environment with
a different architecture than that of the system Python install? I
suspect not, but maybe there's an option I don't know about.
You can solve some of the
problems by editing the Makefile which it uses to learn the compiler
options from.

I don't understand this - do you mean I should edit the Makefile in
the actual distutils package, and somehow use that in my project
instead of setup.py?

— Jason
 
M

Martin v. Loewis

You can solve some of the
I don't understand this - do you mean I should edit the Makefile in
the actual distutils package, and somehow use that in my project
instead of setup.py?

No. A python *installation* has a Makefile, in config/Makefile. If
you want distutils to use different options, you could edit this
Makefile.

Regards,
Martin
 
J

Jason

No. A python *installation* has a Makefile, in config/Makefile. If
you want distutils to use different options, you could edit this
Makefile.

Oh, I see what you mean. But then it would affect *everything* I build
on that machine, so I'll stick with the "separate 32-bit installation"
approach.

Cheers,
Jason
 
B

bobicanprogram

My situation is this: I have a Diamond Systems single-board computer
with a
matching GPIO board. DS have a library for controlling the GPIO
board... but
it's a static library (libdscud-6.02.a) with an accompanying header
(dscud.h).
I'd like to create a Python extension to use the device.

The architecture of the SBC is 486, and it runs Debian Squeeze/Grip.
While it
is possible to develop on it directly, I'd rather use my desktop
machine
(Debian Squeeze, amd64).

If I write a simple C program to control the device, I'd include the
header
file and cross-compile it like so:

gcc -m32 -march=i386 -lpthread -I/usr/local/dscud-6.02 -o dio
dio.c \
/usr/local/dscud-6.02/libdscud-6.02.a

To get myself started with the Python extension, I've basically taken
the
"noddy" demo[1] and thrown in a function call from the DSC library
just to see
if I can get something to build.

My distutils setup.py looks like:

----
from distutils.core import setup, Extension

module1 = Extension('noddy',
sources = ['src/noddy.c'],
libraries = ['pthread'],
include_dirs = ['/usr/local/dscud-6.02'],
extra_objects = ['/usr/local/dscud-6.02/libdscud-6.02.a'],
extra_compile_args = ['-m32', '-march=i386'])

setup(name = 'Noddy', version = '1.0', description = 'This is a demo
package',
ext_modules = [module1])
----

This works fine on the target machine with "python setup.py build",
but when I
try it on my desktop machine, I get:

----
$ python setup.py build
running build
running build_ext
building 'noddy' extension
creating build
creating build/temp.linux-x86_64-2.6
creating build/temp.linux-x86_64-2.6/src
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -I/usr/local/dscud-6.02 -I/usr/include/
python2.6 -c
src/noddy.c -o build/temp.linux-x86_64-2.6/src/noddy.o -m32 -
march=i386
In file included from /usr/include/python2.6/Python.h:58,
from src/noddy.c:1:
/usr/include/python2.6/pyport.h:694:2: error: #error "LONG_BIT
definition
appears wrong for platform (bad gcc/glibc config?)."
error: command 'gcc' failed with exit status 1

----

So is it possible to get distutils to cross compile something like
this, and
if so, what am I missing? Or am I using the wrong tool for the job?

Target python ver. is 2.6. GCC is 4.4.5.

Cheers,
Jason

[1]http://docs.python.org/extending/newtypes.html


Cross compilation might be one solution to Python access. The SIMPL
toolkit (http://www.icanprogram.com/simpl; http://www.icanprogram.com/06py/lesson1/lesson1.html)
might be easier. If you ultimately want to communicate from a 64bit
to a 32bit system, you'll probably want to use a text based tokenized
messaging strategy as opposed to the binary one in these examples.

bob
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top