Python on avr32

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has anybody tried to run python on avr32?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have not, but would be interesting. Do you have any numbers on binary size and/or memory usage when running?

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@HCE
I think he's referring to the python interpreter that JoFreak mentioned in an earlier post that he was using:

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=40262&start=all

Quote:
I should probaby resurrect my avr32-python interpreter ...

Anyone have any ideas on that little pet project?

mcw

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We speak about the same stuff? http://python.org/

AFAIK python can a) compile forever or b) compile when run (like perl, php). That is why I was wondering about memory footprint :) If it can run in less than 8 MB I might get a chance of looking into it. I will see if I can get a comment from JoFreak, maybe he is reading this thread :)

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup, yup same thing; didn't mean to make you think otherwise.

I was hoping to get a comment from JoFreak with my post or possible refresh your memory :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No success so far.
I tried to cross compile python2.3.6 with
./configure --host=avr32-linux --build=i686
and ran make. Below is the error I get
...
c++ -Xlinker -export-dynamic -o python \
Modules/python.o \
libpython2.4.a -lpthread -ldl -lpthread -lutil -lm
/usr/bin/ld: Modules/python.o: Relocations in generic ELF (EM: 6317)
/usr/bin/ld: Modules/python.o: Relocations in generic ELF (EM: 6317)
/usr/bin/ld: Modules/python.o: Relocations in generic ELF (EM: 6317)
/usr/bin/ld: Modules/python.o: Relocations in generic ELF (EM: 6317)
/usr/bin/ld: Modules/python.o: Relocations in generic ELF (EM: 6317)
/usr/bin/ld: Modules/python.o: Relocations in generic ELF (EM: 6317)
/usr/bin/ld: Modules/python.o: Relocations in generic ELF (EM: 6317)
Modules/python.o: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [python] Error 1

Souldn't it be using /usr/avr32-linux/ld? Looking at the configure file, I couldn't see any options to specifiy where the linkers and such are located.
When I tried ./configure with the --without-gcc option, make exits successfully with a few pointer dereferencing warnings. The size of the distribution is about 40Mb. I had a bit of a space constraint moving it to the target. I am not sure if one can move only the *.py, *.pyc or *.pyo python modules. That might reduce the space requirement by a third. Issuing python at the command line, I get an error
~ # python
/bin/python: /bin/python: 1: Syntax error: word unexpected (expecting ")")

As far as the memory footprint...I will try to measure that on a working system and let you know.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bwon23 wrote:

c++ -Xlinker -export-dynamic -o python \
Modules/python.o \
libpython2.4.a -lpthread -ldl -lpthread -lutil -lm
/usr/bin/ld: Modules/python.o: Relocations in generic ELF (EM: 6317)

Now, that's a confusing error message...

The problem is that it's running the wrong linker, which again is caused by the wrong g++ being run. It should really be avr32-linux-c++.

Quote:
Souldn't it be using /usr/avr32-linux/ld?

Exactly.

Quote:
Looking at the configure file, I couldn't see any options to specifiy where the linkers and such are located.

No, it shouldn't be necessary. Specifying --host=avr32-linux should be enough, but I guess someone might have tried to be clever with the configure script and screwed up cross-compilation in the process...

Quote:
When I tried ./configure with the --without-gcc option, make exits successfully with a few pointer dereferencing warnings. The size of the distribution is about 40Mb. I had a bit of a space constraint moving it to the target.

Hmm...that's quite big. Maybe you can strip some binaries (using avr32-linux-strip) to reduce the size?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Hmm...that's quite big. Maybe you can strip some binaries (using avr32-linux-strip) to reduce the size?

What I meant by distribution size was binaries(4-filels approx 3Mb) + modules (*.pyo,*.pyc,*.py,*.so etc... approx 35Mb). I guess a user who does not need to import some of the modules into their script can leave them out conserving space.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did this in a very early phase of the AP7000 project (for the sheer fun of it) and linked the interpreter with a few select modules statically. It worked like a charm, although how is right in the fact that someone was outsmarting themselves in the configure-script for cross-compilation.

If my memory serves me right, the problem is a mixup of buildhost and target since it's a (at least) 2-pass compile to get python built and it needs some target-specific binaries to build the interpreter (pgen).

I'll see if I can resurrect the patch from Somewhere [tm], although I believe my patch was primarily a copy of the arm cross-compile cookbook:
http://www.ailis.de/~k/docs/crosscompiling/#python

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If anyone is interested, I have created a patch for Python 2.3.6. I want to give credit to Klaus Reimer, as the patch is an update from his patch for python 2.2.1.

Follow the instructions at the link that JoFreak has kindely given us above.

I believe the cross-compile has gone without a hitch, but I need to build libstdc++ now as python needs it at run time. It never ends :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If anyone is interested, I have created a patch for Python 2.3.6. I want to give credit to Klaus Reimer, as the patch is an update from his patch for python 2.2.1.

Follow the instructions at the link that JoFreak has kindely given us above.

I believe the cross-compile has gone without a hitch, but I need to build libstdc++ now as python needs it at run time. It never ends :(

(sorry about the double post. attachment didn't work the fist time.)

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice - I'll have to try it out!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Bwon,

I used your patch and followed the instructions located at http://www.avr32linux.org/twiki/...

This is an avr32 specific derivative of the arm example above. (This was written by JoUthus at avr32linux.org which I think is the same as JoFreak here)

Following the instructions, I basically did the following:

Quote:

# patch -p0 < avr32-crosscompile.patch
# configure
# make python Parser/pgen
# mv python hostpython
# mv Parser/pgen Parser/hostpgen
# make distclean

Prepare for cross-compilation:

# ./configure --target=avr32-linux --prefix=$HOME/install/us

# make CXX=avr32-linux-g++ \
CC=avr32-linux-gcc \
AR=avr32-linux-ar \
RANLIB=avr32-linux-ranlib \
HOSTPYTHON=./hostpython \
HOSTPGEN=./Parser/hostpgen \
BLDSHARED="avr32-linux-gcc -shared"

and as the instructions on avr32linux.org warned me, I got the following errors:

Quote:
# ./Modules/posixmodule.c:1170: error: "struct stat" has no member named "st_atim"
# ./Modules/posixmodule.c:3362:21: error: stropts.h: No such file or directory

Now, you've said that "I believe the cross-compile has gone without a hitch" so I take it you didn't have this problem? If so, could you tell what Jo has done differently?

Thanks..