A couple of weeks ago, I
hinted at a presentation that I wanted to do during this year's GUADEC, as a Lightning talk.
Unfortunately, I didn't get a chance to finish the work that I set out to do, encountering a couple of bugs that set me back. Hopefully this will get resolved post-GUADEC, so you can expect some announcements later on in the year.
At least one of the tasks I set to do worked out, and was promptly obsoleted by a nicer solution. Let's dive in.
How to compile for a different architecture
There are four possible solutions to compile programs for a different architecture:
- Native compilation: get a machine of that architecture, install your development packages, and compile. This is nice when you have fast machines with plenty of RAM to compile on, usually developer boards, not so good when you target low-power devices.
- Cross-compilation: install a version of GCC and friends that runs on your machine's architecture, but produces binaries for your target one. This is usually fast, but you won't be able to run the binaries created, so might end up with some data created from a different set of options, and won't be able to run the generated test suite.
- Virtual Machine: you'd run a virtual machine for the target architecture, install an OS, and build everything. This is slower than cross-compilation, but avoids the problems you'd see in cross-compilation.
The final option is one that's used more and more, mixing the last 2 solutions: the
QEmu user-space emulator.
Using the QEMU user-space emulator
If you want to run just the one command, you'd do something like:
qemu-static-arm myarmbinary
Easy enough, but hardly something you want to try when compiling a whole application, with library dependencies. This is where
binfmt support in Linux comes into play. Register the ELF format for your target with that user-space emulator, and you can run
myarmbinary without any commands before it.
One thing to note though, is that this won't work as easily if the qemu user-space emulator and the target executable are built as a dynamic executables: QEmu will need to find the libraries for your architecture, usually x86-64, to launch itself, and the emulated binary will also need to find its libraries.
To solve that first problem, there are QEmu static binaries available in a number of distributions (
Fedora support is coming). For the second one, the easiest would be if we didn't have to mix native and target libraries on the filesystem, in a chroot, or container for example. Hmm, container you say.
Running QEmu user-space emulator in a container
We have our statically compiled QEmu, and a filesystem with our target binaries, and switched the root filesystem. Well, you try to run anything, and you get a bunch of errors. The problem is that there is a single binfmt configuration for the kernel, whether it's the normal OS, or inside a container or chroot.
The Flatpak hack
This commit for Flatpak works-around the problem. The binary for the emulator needs to have the right path, so it can be found within the chroot'ed environment, and it will need to be copied there so it is accessible too, which is what this patch will do for you.
Follow the instructions in the commit, and test it out with this
Flatpak script for GNU Hello.
$ TARGET=arm ./build.sh
[...]
$ ls org.gnu.hello.arm.xdgapp
918k org.gnu.hello.arm.xdgapp
Ready to install on your device!
The proper way
The above solution was built before it looked like
the "proper way" was going to find its way in the upstream kernel. This should hopefully land in the upcoming 4.8 kernel.
Instead of launching a separate binary for each non-native invocation, this patchset allows the kernel to keep the binary opened, so it doesn't need to be copied to the container.
In short
With the work being done on Fedora's static QEmu user-space emulators, and the kernel feature that will land, we should be able to have a nice tickbox in Builder to build for any of the targets supported by QEmu.
Get cross-compiling!
