Over a decade after its launch, the Zaurus is still a useful pocket computer but its 64MB RAM limitation can be restrictive, especially when it comes to building large programs. The Zaurus simply doesn't have enough RAM to compile some large source files and it just enters 'swap hell' when it gets overwhelmed. On top of this, the Zaurus is slow to compile programs it can manage so it can be a huge time saver to get a cross-compilation environment set up which enables you to utilize more powerful machines to accelerate or simply enable the building of complex software.
The cross compilaion method recommended by the ALARM developers and ultimately the fastest way to cross compile software is to use distcc. In most cases you should try setting up distcc by following the ALARM developer distcc guides first before you resort to the ARM cross compiling method described here.
http://archlinuxarm.org/developers/distributed-compilinghttp://archlinuxarm.org/developers/distcc-cross-compilingTo use this guide you need to be familar with the Arch package management tools and you need an ARM-based computer running ALARM that has superior specs to the Zaurus and internet connectivity so that it can download development packages. If you don't already own a modern ARM computer and you're on a tight budget then I can highly recommend the Banana Pi, which is about the same price as the RPi2 but with SATA2 and gigabit ethernet. It's not officially supported by ALARM, like the Zaurus, but also like the Z it runs ALARM very well nonetheless. If you have more money to spend you might want to check out something like the Odroid XU4 which has 2GB RAM, a faster CPU and USB3. Check out
http://archlinuxarm.org for a list of supported platforms.
The key bit of software used in this guide is arch-chroot which is part of the arch-install-scripts package. I have only tested chrooting from an Arch armv7 userland into an Arch armv5 but you could probably run arch-chroot under another modern ARM Linux distro that uses systemd and get the same results. To keep things simple it is recommended you stick to ALARM for the host OS but I'm interested to hear from anyone who tries this under a non Arch-based ARM Linux distro. This guide should work for machnes running armv6h and aarch64 too.
First you need to download and extract the ALARMv5 rootfs:
$ wget http://archlinuxarm.org/os/ArchLinuxARM-armv5-latest.tar.gz
$ mkdir ~/ALARMv5
# bsdtar xvf ArchLinuxARM-armv5-latest.tar.gz -C ~/ALARMv5Note that the extraction of the rootfs (the bsdtar command) needs to be done as root to preserve the files users and permissions but otherwise you can extract it where you wish.
Presuming that the host machine is connected to the internet, copy the host machines resolv.conf into /etc of the chroot fs:
# cp /etc/resolv.conf ~/ALARMv5/etcYou should now be able to chroot into the ALARMv5 rootfs:
# arch-chroot ~/ALARMv5Now you're logged into the chroot, you can build Arch packages just as you normally would but there are two main things you should check when configuring an Arch package for cross compilation.
First you need to check the 'arch' statement in the PKGBUILD script for the package you are building includes 'arm'. If it doesn't then add it in so that the arch line looks like:
arch=('i686' 'x86_64' 'arm')If the package you are building uses autoconf with a configure script then you need to add the correct --build switch option to the ./configure statement within the build() function of the PKGBUILD script to make sure the compiler builds for armv5 instead of armv7 or whatever platform your host is running. It will look something like this after modification:
build() {
cd $srcdir/$pkgname-$pkgver
./configure --prefix=/usr --build=armv5tel-unknown-linux-gnueabi || return 1
make || return 1
}You might have to do some investigation to work out how to tell your app to build for armv5tel-unknown-linux-gnueabi if it doesn't use autoconf. You can often set the arch to build for by exporting it as an environment variable but I wouldn't worry too much about trying to specify the target build arch as in most cases the resultant packages will work regardless.
Providing you have enough disk space I would recommend you install your packages under the chroot after they have finished building. Not only does ths act as a test of ther validity but it is a backup too should you quit out of the chroot before backing the package up.
makepkg, packer and pacaur etc store the finished package under /tmp directory. packer for example stores its packages under /tmp/packerbuild-0/$PKGNAME/$PKGNAME where $PKGNAME is the name of the package you built. Make sure you copy the package out of the /tmp dir of the chroot after building and before you exit the chroot because everything under /tmp gets deleted as soon as you exit the chroot, which you do by typing 'exit' or hitting CTRL+D.
If you do ever need to create an Arch package from one that was previously installed but for which the package no longer exists (for example if you quit out of the chroot before copying the package out of /tmp) then you can use bacman to create the package, which comes as standard with pacman. Using it is as simple as running:
$ bacman packagename
Show Posts