Ok, I ‘ve been off for a little time right now. The main reason, is that I spend some time hacking my new Wireless access point: WRT54GS.
I spend a lot of time tweaking the config to use this in client mode with dhcp thought the WAN port and other nuts. I spend some time on http://www.brest-wireless.org too. But this is the mean reason of this post :)
Some people would think I’m a crazy boy but this is perhaps true. I managed to cross-compile python for the WRT. If you ask me why, I would simply answer that there is a lot of network stuff on a WRT that can be writen in a couple of python lines: dhcpd, dns cache, http server, dynamic pages rendering, dynamic firewall rules (check out last posts ..), diagnostics tools .. That’s it, now we need to figure out if this is do-able :)
WRT use a broadcom misp processor, so we need:
- to install a cross-compile environnement: Not to hard.
- tweak the python Makefile to use this, a little more funny but it works.
- first tests..
As you can imagine, this doesn’t work at all :) The main issue is that current python use g++ (2.3), and the WRT only came with uClib, not the uClib++. After this wrong experience, I decided to take a old python: 1.5.2 . This one only needs gcc fine ! Ok, let’s see the result:
telnet host50 Trying 192.168.1.50... Connected to host50.soif.fr. Escape character is '^]'. BusyBox v1.00 (2004.11.20-09:17+0000) Built-in shell (ash) Enter 'help' for a list of built-in commands. @OpenWrt:/# /tmp/python Could not find platform independent libraries <prefix> Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] 'import exceptions' failed; use -v for traceback Warning! Falling back to string-based exceptions 'import site' failed; use -v for traceback Python 1.5.2 (#2, Nov 21 2004, 05:52:09) [GCC 3.2.3 with Broadcom modifications] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import sys >>> import os Traceback (innermost last): File "<stdin>", line 1, in ? ImportError: No module named os >>>
As you can see on this little capture, some parts of the interpreter works, but other don’t. The main issue is the build of modules. Something goes wrong at the link (ld), and I was unable to fully compile this.
Anyway this is not a big issue, because right now, I don’t think python 1.5.2 is a great challenger anyways. For people interested the python exec does 1.6Mo but a WRT54GS has 6Mo of free ROM.
I would really enjoy to hear your comments about your experience w/ ‘embeded python’. I guess that java has this kind of cross-compile issue too, but java is ready for cellphones, or other stuffs. Why not python ?
I ported Python 2.3 to a 4 meg (ram) 68K Arcturus board using uClibc. I also included libxml2 and libxslt statically linked.
It worked ok, but there were issues with posix threads.
I did this over a year ago. It’s probably easier now and perhaps threads really work instead of deadlock.
This is excellent. I think python could do a lot for embedded control where interpreted basic is the most common HLL.
Does anyone have luck doing a conditional compile of the different builtin modules? What is the smallest size that the python vm could get down to?
It would be interesting to remove the compiler and only provide the ability to run .pyc files.
Brad how do you manage to use gcc instead of g++ ?
Is there a embeded python SIG somewhere ?
This is so out of date, but for reference, ./configure –without-cxx
Yes, this thread is out-of-date.
I got python working on an ARM9 linux system; The latest (2.4.4) version of python compiled fine using scratchbox. The stripped executable is 1.0MB, but I needed to include a couple libraries. I
also took a bunch of the .pyc files from /usr/local/lib/python2.4, and they seem to work well.
(lib-dynload seems quite important)
Mike