Cross-Compiling the RetroPie

[mitu]

I discovered the RetroPie project a while ago and built a RPI 3 with it to givea as a gift for a friends' kids. I'd like to thank you for putting it all together and making it easy to just install an image to the PI and dealing with all the configuration and knobs of various emulators.

While building the first system, I read a lot of topics here, trying to improve on the system and make it more kid friends, and at the time I stumbled upon the topic with the new features of ES being added (PowerSaving and the Favorites/All/Last Played collections). I realized that people would compile ES directly on the RPI system and thought - wouldn't it be handy to be able to cross-compile it on a more powerfull PC ? So I tried a few ways to cross-compile and it took a few tries (ok, a lot of tries) to be able to do it reliably and correctly.

After succeeding in cross-compiling ES, I thought that would be also handy to be able to cross-compile the other packages - emulators, the libretro cores. So I thought of a way to extend the RetroPie setup scripts to be able to cross-compile various modules, with minimal fuss and as easily as possible.

Long story short, I copied the default packages.sh script into a new script and made it able to invoke the cross-compilation process as easily as running

platform=rpi1 ./cross.sh emulationstation build

You can see a sample output at https://ghostbin.com/paste/u5bvq (this took about 4 min on a VM running on a relatively recent 4 core system). The host system is Debian Stretch (x86) and the buildroot is a Jessie Raspbian (armhf) system.

I also tested more than 50% of the emulators and lr- cores using this method and I'd say the cross-compilation is possible with minor patches to their build configuration files (makefiles/configure/cmakelists.txt).
In addition to that, I make some scripts to also generate the build infrastructure:

• a buildroot (rootfs) for the target system
• a cross compiler suited for the target system.

I've been succesfully running RetroArch/ES and a few lr- cores to test the viability of the binaries and I didn't notice any problems.

If you're interested in the possibility of adding cross-compilation to the RetroPie-Setup scripts, I'd be more than willing to expand on my experiment and perhaps go further than that.

But for now, I'd like to gauge the interest in this possibility and - if yes - what people/devs would like to look like.

[herb_fargus]

@mitu @BuZz has a chroot system with qemu that he uses to build the release images, I'm not super familiar with his code but I believe at least a portion of it is available in the setup script and I'd be willing to bet it uses cross compiling.

[mitu]

@herb_fargus said in Cross-Compiling the RetroPie:

@mitu @BuZz has a chroot system with qemu that he uses to build the release images, I'm not super familiar with his code but I believe at least a portion of it is available in the setup script and I'd be willing to bet it uses cross compiling.

You mean the scripts from tools/sdcard ? I thought they're used to create the .img file (like running commands in the image, copying stuff, configuring services).

Doesn't compiling in a the qemu chroot takes more than cross-compiling ? Since it involves the arm->x86 translation performed by qemu-arm-static, I expect it to be slower than a native compilation done by a cross-compiler.

[jdrassa]

@mitu I would be interested in being able to cross compile EmulationStation outside of RetroPie-Setup. As I am developing, it would be a lot easier to just kick off the build directly vs. relying on RetroPie-Setup. It would also be useful for automatically generating dev builds for testing.

[mitu]

@jdrassa What is your developping environment ?
The solution I'm testing uses a Linux (either Debian or Ubuntu) host to compile for the RPI, but I know you provide the ES Windows builds - would cross-compiling on Windows be more convenient for you ?

[BuZz]

@mitu not interested in cross compiling in RetroPie as it would require additional maintenance for all the modules (and when adding new ones). However it's already technically supported via distcc. I build all binaries in an emulated chroot with a cross compiler on the host (and other machines) which are used via distcc. No customisations needed for makefiles etc then.

[mitu]

@buzz OK, thanks for taking the time to reply.
I understand the maintenance worries - given the large number of modules, it would be extra work to keep them in shape for any possible breaking changes. While the build system patches could be submitted upstream, the cross-compile build system would still be different enough from the native compilation to warrant an extra-test.

[BuZz]

@mitu Also my existing cross compiling set-up is fast enough. Even though it uses an emulated chroot with the cross compiler called via dist cc (which means linking and os stuff is done via emulation) it has the advantage of having an identical system as a rpi would, so it's good for testing.

Can also use the distcc method via a real RPI, for quick binary building and testing.

I used this script (I didn't write it, but it may have my modifications - I have been meaning to do a rewrite and eventually include it with RetroPie-Setup) to build the cross compiler on the host

https://paste.ubuntu.com/25619083/

Some of the chroot stuff is in RetroPie-Setup but needs a wrapper script. I intend to include more of this code in RetroPie-Setup at some point when it's been cleaned up.

I use something like this to build the binaries (need to implement the chroot/chroot-dev scripts into retropie-setup still). The setup-links script is a simple script to switch the parent distcc compiler to match the version of the Raspbian one. The script below is called with module XXX YYY or section core/main/opt to build multiple binaries

#!/bin/bash
params=("$@")
home="/home/pi"
for dist in jessie; do
    ~/Repos/RetroPie/RetroPie-Setup/retropie_packages.sh image chroot
    ./chroot.sh ~/Repos/RetroPie/RetroPie-Setup/tmp/build/image/chroot bash -c "sudo apt-get update; sudo apt-get install -y git dialog xmlstarlet distcc; sudo sed -i s/\+zeroconf/192.168.1.8/ /etc/distcc/hosts"
    for plat in rpi1 rpi2; do
        cd "$home/scripts"
        ./setup-links.sh "$dist" >/dev/null
        ./chroot-dev.sh ~/Repos/RetroPie/RetroPie-Setup/tmp/build/image/chroot sudo PATH=/usr/lib/distcc:$PATH MAKEFLAGS="-j4 PATH=/usr/lib/distcc:$PATH" __platform="$plat" /home/pi/RetroPie-Setup/retropie_packages.sh builder "${params[@]}"
    done
done

if on a rpi - can use a distcc on another machine by just doing (once distcc is installed and configured on the remote machine and on the rpi to use the remote machines ip)

sudo PATH="/usr/lib/distcc:$PATH" MAKEFLAGS="-j4 PATH=/usr/lib/distcc:$PATH" __platform=rpi2 ./retropie_packages.sh WHATEVER`

[mitu]

@buzz Funnily enough, the cross-compiler toolchain script I used is almost the same - based on the http://preshing.com/20141119/how-to-build-a-gcc-cross-compiler page. I couldn't find an OOB cross-compiler to support all RPI cpus and be multi-arch capable.

To create the chroot, I use Sbuild and a script like http://pastebin.ubuntu.com/25619123/. It's simple enough and can be adapted for building Debian based chroots (Stretch/Ubuntu). You probably have something similar for contructing the buildroot.
The advantage of using sbuild is that you can easily add new packages in the buildroot, in fact my cross-compiling scripts override the getDepends function and use sbuild to add the dependencies.
My scripts are at https://github.com/cmitu/RetroPie-Setup/tree/x-tools/cross, but they're not documented enough and it's missing the buildroot/toolchain building scripts.

[BuZz]

@mitu the emulated chroot is created via RetroPie-Setup. See admin/image module. It's created from raspbian lite image, so it's identical to a real install which is good for catching problems and dependency issues.

It's used for building the images too which uses qemu again on a pc.