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/arch.in
IN config.gen/kernel.in
IN config.gen/cc.in
IN config.gen/binutils.in
IN config.gen/libc.in
IN config.gen/debug.in
CONF config/config.in
#
# configuration written to .config
#
***********************************************************
Initially reported by: Yann E. MORIN
URL: https://ymorin.is-a-geek.org/
Comment:
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.
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
macros:
run:
usage: xcompile and qemu TurboLoader in a docker container
docker_image: aretroui
privileged: true
enable_gui: true
security_opts:
- 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