Cross-compiling binaries for multiple architectures with Docker

Cross compiling toolchains today

When embarquing into embedded systems development to fix relatively old hardware, a need becomes clear fairly early: recompiling software on an embedded system becomes a daunting task due to too old base system or simply irritatingly slow to iterate.

That is why distributions such as Debian really shine with their support and commitment for multiple architectures. So all is fun and happy development until someone reaches out to the documentation on how to setup a cross-compiling toolchain.

But wait, there’s crosstool-ng, seems to be a wrapper that could help me cross-build my binaries…

$ ct-ng armv5-linux-gnueabi
make: *** No rule to make target `armv5-linux-gnueabi'.  Stop.
$ ct-ng armv6-rpi-linux-gnueabi
  LN    config
  MKDIR config.gen
  IN    config.gen/
  IN    config.gen/
  IN    config.gen/
  IN    config.gen/
  IN    config.gen/
  IN    config.gen/
  CONF  config/
# configuration written to .config


Initially reported by: Yann E. MORIN

Toolchain for the Raspberry Pi, with hard-float.


So that is hard-float raspberry pi support by default, which will give me an Invalid Instruction exception so I should activate CT_ARCH_FLOAT_SW in the .config and then… sigh.

Dockerize compiling away

Cross compiling toolchains with DockCross

Enter dockcross where after a small pullrequest to support ARMv5 with no hard-float support and installing the dockcross tool once:

$ docker run thewtex/cross-compiler-linux-armv5 > ~/bin/dockcross
$ chmod +x ~/bin/dockcross

Cross-compiling for your drone, your favorite reverse engineering framework or your shader-based RetroPie frontend is just two commands away:

$ dockcross --image thewtex/cross-compiler-linux-armv5 ./configure --with-compiler=armel --host=armel
$ dockcross make

For an extra icing in the cake, it is worth mentioning that DockCross also supports QEMU emulation that can be used in the same container, right after your binaries are built.

Furthermore, for the cherry in the cake, have a look at TravisCI running QEMU for ARM, unbelievable.

Happy hacking and x-compiling!

QEMUlating SDL/OpenGL inside Docker for Mac?

Using Nut to spawn containers with X11 support:

$ cat nut.yml
syntax_version: "6"
project_name: TurboLoader
    usage: xcompile and qemu TurboLoader in a docker container
    docker_image: aretroui
    privileged: true
    enable_gui: true
    - seccomp=unconfined

While other apps such as Chrome work well, raw OpenGL shader support is unfortunately not there yet in Docker’s HyperKit under OSX (hint: use native Linux instead for now with nvidia-docker):

$ nut run
** Test project **
¿¿ Smoke test Lua ??
¿¿ Startup environment ??
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  150 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  82
  Current serial number in output stream:  83