sil2100//vx developer log

Welcome to my personal web page



Today will include a small advertisement-like post. Cross compilation has always been a bothersome process. Right now it's not as bad as it once was though - yet, still it can be time consuming, especially if you want to create you own GNU/Linux system for a different platform. For proper cross-compilation, we first need a specific toolchain present that will be able to generate code for our architecture of interest (we can use crosstool or OpenWrt here, for instance). Usually, this can be a troublesome as well, even more if the platform we're interested in is relatively unpopular - but we will skip this case for now and return to it in a later post.


There are many ways of building applications for non-local architectures. Having a ready toolchain it's really just a matter of using their binaries instead of ours. OpenWrt, for instance, uses their so called buildroot - a cross compilation system utilizing Makefiles. Most cross-magic is done there thanks to the power of configure and Makefile scripts, allowing different binaries from the toolchain to be used instead of the local ones. Not bad.

In one of my first posts I wrote that I prefer Fakebox - a cross compilation toolkit developed some time ago by ASN (advertisement!). Fakebox, similarly to Scratchbox, attempts to emulate a Linux machine on a Linux machine. I never used Scratchbox before, but from what I heard from my colleagues, even though it really does everything you need and it does it really good, it can be a troublesome and complex beast. That is why they created Fakebox, a much simpler toolkit for the same purpose. It's really interesting how such a simple thing can work well for most uses.

Fakebox is nothing more then a batch of shell scripts and configuration files. To get it working, all you need is the toolchain and qemu installed. How does it work? The Fakebox website actually explains it nicely. What Fakebox does is:

After this is done, we can run and compile programs for the specified architecture as we please. Since we are using binfmt_mist, all executables are ran using qemu emulation (e.g. qemu-mips or qemu-arm), so we can use them later on in the build process. Fakebox has its problems, but for what it is, it's still sufficient.

For instance, if we would like to setup an environment for a mips architecture in Fakebox (latest version from the git repositories), our fakebox.conf could look like this:


FB_UNAME="Linux amatsu 2.6.31 #1 Mon May 7 20:21:51 CEST 2007 mips unknown"


FB_FTPAGENT="wget --continue --passive-ftp --tries=3 --waitretry=3 --timeout=10"


After putting this configuration file in the mips/ directory, we can run our new environment by typing "fakebox mips/". Fakebox then sets the $PATH variable to include our custom paths (FB_PATH), our toolchain path, our fakebox wrappers and so on, registers binfmt_misc for our architecture (if supported) and runs a new shell. Besides emulation, Fakebox also offers an integrated simple package manager with building capabilities (pkgtools) with overall functionality similar to the ones seen in OpenWrt (with the exception of being implemented in bash instead).
This is a very nice feature of Fakebox as well. You can organize your applications/libraries as packages, download and build them easily when needed. After a package gets build, you can then install/uninstall it on the target root file system with one command. It saves up some time and makes development cleaner. Since it's an important feature, I will return to it in the next post about Fakebox. Stay tuned.