Cross compiling (i386 from amd64) with distutils

Discussion in 'Python' started by Jason, Nov 8, 2010.

  1. Jason

    Jason Guest

    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
     
    Jason, Nov 8, 2010
    #1
    1. Advertising

  2. > 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
     
    Martin v. Loewis, Nov 8, 2010
    #2
    1. Advertising

  3. Jason

    Jason Guest

    On Nov 8, 8:30 am, "Martin v. Loewis" <> wrote:
    > 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
     
    Jason, Nov 8, 2010
    #3
  4. Jason

    Jason Guest

    On Nov 8, 8:55 am, Jason <> wrote:
    > 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.


    Found a better solution, which is to just compile Python from source
    to be 32 bit. This is from:

    http://indefinitestudies.org/2010/02/08/how-to-build-32-bit-python-on-ubuntu-9-10-x86_64/

    Thanks for your help,
    Jason
     
    Jason, Nov 8, 2010
    #4
  5. >> 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?


    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
     
    Martin v. Loewis, Nov 8, 2010
    #5
  6. Jason

    Jason Guest

    On Nov 8, 4:16 pm, "Martin v. Loewis" <> wrote:
    > 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
     
    Jason, Nov 8, 2010
    #6
  7. On Nov 7, 7:19 pm, Jason <> wrote:
    > 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
     
    bobicanprogram, Nov 9, 2010
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mathias Waack
    Replies:
    3
    Views:
    474
    Andrew MacIntyre
    May 27, 2007
  2. Otacon22
    Replies:
    1
    Views:
    325
    Paul Boddie
    Oct 23, 2007
  3. Luke Kenneth Casson Leighton
    Replies:
    0
    Views:
    505
    Luke Kenneth Casson Leighton
    Dec 31, 2008
  4. Garrett Cooper
    Replies:
    0
    Views:
    589
    Garrett Cooper
    Feb 24, 2009
  5. Replies:
    0
    Views:
    155
Loading...

Share This Page