Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Hi,
I'm wondering whether it would be possible to port Python to DNS-323? Would it be possible to run Trac or Plone on it?
Cheers,
Bernhard
Offline
It's possible to compile python 2.5.1 with this guide: http://whatschrisdoing.com/blog/2006/10 … python-25/
The patch needed some manual work before all chunks were done thought.
Offline
I managed to cross-compile Python2.5 by following the procedure given by Chris (and Reimer) on the referred web page. You can download the archive with the binaries for fun_plug from
http://rapidshare.com/files/74345952/py … ar.gz.html
Just extract the archive into /mnt/HD_a2/fun_plug.d and you'll get the file python2.5 into the /bin directory and the libraries into the /lib/python2.5 directory. To make it run, you'll have to make python2.5 an executable by
chmod 555 /mnt/HD_a2/fun_plug.d/bin/python2.5
and set the environment variables PYTHONHOME and PYTHONPATH using the following commands:
export PYTHONHOME=/mnt/HD_a2/fun_plug.d/lib/python2.5
export PYTHONPATH=/mnt/HD_a2/fun_plug.d/lib/python2.5
If you wish to call "python" (instead of "python2.5") you have to establish a symbolic link using:
cd /mnt/HD_a2/fun_plug.d/bin
ln -s python2.5 python
fonz, maybe you could include Python into fun_plug 0.4 :-)
cheers,
Bernhard
Offline
Later that night I recognized that there are some built-in classes missing due to compiler errors during the build. For instance, the library "datetime" is missing. The compiler errors result from inline assembler instructions for x86_64 and i386 architecture. Of course the arm-linux-gcc will fail translating them.
I'll give it another try this evening...
Offline
I cannot make Python running properly on the DNS-323. Some things do work, others don't.
Main problem seems to be the shared objects. For instance, if you try to import a built-in Python library, such as "time", the shared object "time.so" is loaded from the directory .../python/lib/python2.5/lib-dynload/. This results in an error message that the symbol "__deregister_frame_info" cannot be resolved.
I've started Python with -v option to get more information:
>>> import time dlopen(”./time.so”, 2); : can’t resolve symbol ‘__deregister_frame_info’
This __deregister_frame_info symbol is probably defined in libgcc_s.so.1 but even if this file exists in /mnt/HD_a2/fun_plug.d/lib the error message still occurs.
Does anybody have a good idea (beside chroot into debian :-)?
Bernhard
Offline
Most likely the python cross-compiled for the DNS-323 was built against a different uclibc (though I'm not an expert). I had a lot of troubles when trying to exchange the uclibc installed on the device with the one I compiled when building the tool chain (http://dns323.kood.org/howto:crosscompile) and still didn't get it running. After being lucky to "recover" my DNS-323 I gave up trying to get Python running natively.
I chroot'ed into debian (sarge). This enables me to do all the things I wanted to.
Bernhard
Offline