How to run debian-mipsel application on dingux (even if you're NOT a linux-ninja)
I'll try to keep all this as much simple as possible, so that (almost) everyone can read it (and hopefully report his experience) even if he's NOT a linux-ninja-developer (surely I'm not that). It could take a while though...
After having discussed the subject with cyberic99 in this thread
I finally managed to run a simple application (nano-tiny) that came from the debian-mipsel repository (www.debian.org
). If the procedure I am suggesting here, will prove effective with other software, I think we can get a lot of useful application without the need of a custom recompilation (probabilly with some limitation regarding performance though).
The first thing I have to say is that as far as I know, the most of the applications included into a generic linux distribution (like debian) are dinamically compiled. This means that the executable is *linked* to shared library files that are suposed to be available into the system (usually in the folder /lib, or /usr/lib, or /usr/local/lib ). This is useful in order to reduce the dimension of a single executable.
For instance, if you try to compile an "hello world" application dinamically (this is the default), your executable will be very small, since it doesn't actually contains the code of your printf() call, but just a *link* to it. Otherwise if you perform the same compilation statically (BTW: if you're using gcc, you just have to add the --static option), the executable will be noticeabily wider, since it will embed the printf() code. This is obviously a waste of space in your hd, since you still have the printf() code resident somewhere in your system.
The interesting thing of static compilation is that the whole code needed to run the executable is in that binary file, so that it can be executed into every machine that supports the same instruction code (=same cpu) an the same system calls (in the case of a UNIX-like system, POSIX compliant?).
Let's return to our favourite linux system (aka dingux)... it has a set of very optimized custom-compiled libraries generously provided us from booboo (lib-uClibc?). These are obviously not compatibile with any other system, but this doesn't mean that on dingux we can't run application not specifically compiled for it: as explained before, we could run every application statically compiled for the same cpu (mips with little endiannes, in short mipsel). We could even run dinamically compiled apps, if we provide the needed libraries. That's exactly what I've done ( thanks cyberic99 for explaining! ;-) ). In fact the debian guys provide us a bunch of compiled applications, ready to work on a mipsel system (and their libraries as well), so that we can just take them and run on our dingoo (well maybe it's actually not THAT easy)!
Every app is available from the debian repository in the form of a .deb file, which in a nutshell is a just compressed archive, containing the binary and eventually some libraries (and some other things too, but let's keep it short). Shared libraries are supplied themselves in the same way. So, chosen an application (let's say nano-tiny, available at http://packages.debian.org/unstable/editors/nano-tiny
) in order to be able to make it run, we will need its package, and all its related *dependencies* archives as well. For instance, the nano-tiny package (nano-tiny_2.0.9-2_mipsel.dev) depends on libc6 (libc6_2.9-21_mipsel.deb) and libslang (libslang2_2.1.4-3_mipsel.deb) too. So how can get we the binary files included into this archives? The debian system provides us the proper tool: dpkg-deb. To extract the files we just have to type from a console shell of a debian system (like ubuntu), something like:
dpkg-deb -x my_deb_file.deb my_destination_folder
In order to make available a single library folder to our dingux system, we have to merge into one, all the /lib subfolders from the extracted archives, while the executable files (just like nano-tiny), are in the /bin subfolder. In short, in order to run a generic application we need just two things:
1) the binary file of the application itself
2) a folder that contains the library files needed (linked) by the application
Well, once we got those two things we could just copy them into our SD card, but...
Unfortunately library folders often contain special files called "symbolic links", that cannot be created into a FAT32 partition (=filesystem) like that of our dingux-powered SDcard. Disappointing issue! As far as i can understand, in order to keep the system "lightweight", at the moment dingux supports just two kinds of filesystem: FAT32 and romfs.
Romfs... What's that? Do you remember that file called rootfs, that you copied into the SD? It's just a filesystem (=directories+files structure) in a romfs format. As the name suggest (R.O.M.= Read Only Memory) is a read-only filesystem, so how can we create it? A proper tool named genromfs can be used for that. For instance I created a folder where I copied the /lib subfolder containing all nano-tiny dependencies and the nano-tiny executable itself, then I moved to that directory and from a shell typed:
genromfs -f nano.goo
if you do the same, you'll can see that a nano.goo file will have been created, that you can (finally!) copy into the SD into the /local folder.
Let's switch to dingux! Power your dingoo while pressing select!MMMM... I was just wondering that nano is a console application, so we'll have to get a console access. Just plug the dingoo to your computer through the usb cable, then from a shell you can connect to a serial console using the command:
Congratulations! You are now "into" the dingux system (just entered the matrix)! Well, all the files into the /local folder are mapped into the /usr/local folder of the dingux system, so you'd better switch to that typing:
you should see an entry named nano.goo that represents the file we're intrerested in. You got it? We need now to get back those file we had extracted from the .deb files, and then repacked into the .goo file. All we have to do in this case is to *mount* the filesystem.
The Unix command line utility mount instructs the operating system a file system is ready to use, and associates it with a particular point in the system's file system hierarchy (its mount point)
First we have to get a mount point, then. It's a simple empty directory that we can create typing
Then we can mount our filesystem
mount -t romfs -o loop nano.goo /usr/local/nano
Now that we can access the files, we have to instruct the system to execute the binary /usr/local/nano/nano-tiny, using the libraries contained into the /usr/local/nano/lib folder. *In theory* one could point the new library folder changing the value of the environment variable $LD_LIBRARY_PATH, but neither in my ubuntu system, nor in dingux i've been able to read it value (can someone explain this?). So i had to follow the other known way...
This implies calling explicitly the system loader from the shell and specify to it the library folder. The libc6 library we put in the /lib subfolder contains a system loader (ld-2.9.so), we can (finally!) tell him to execute our nano-tiny with this command
/usr/local/nano/lib/ld-2.9.so --library-path /usr/local/nano/lib /usr/local/nano/nano-tiny