The Docker images which can be created using the content provided are used to build third-party libraries and create framework releases across architectures for Linux. The images rely on QEMU for emulation and as a result receive a considerable performance overhead. For third-party libraries this is arguably outweighed by the convenience provided.
Commands starting with a # should be run as superuser / root
These processes were developed on a Debian-based Linux distro and were executed as a regular user. In theory the processes described within could be run on other OSes and distros, but the instructions below focus on Linux.
First you need Docker and QEMU
$ apt install docker.io qemu-user-staticAdd yourself to the Docker group, this ensures that when the docker daemon starts it creates a socket accessible by all members in the docker group, instead of only root.
$ sudo groupadd docker
$ sudo usermod -aG docker $USER
$ newgrp docker Verify that you can run docker commands without sudo:
$ docker run hello-worldFollow the instructions on the Docker Buildx page to get Buildx installed, running eg. $ docker buildx version to verify its installation.
At time of writing, installing buildx (0.8.2) requires the following steps:
$ wget https://github.com/docker/buildx/releases/download/v0.8.2/buildx-v0.8.2.linux-amd64
$ mkdir -p ~/.docker/cli-plugins
$ mv buildx-v0.8.2.linux-amd64 ~/.docker/cli-plugins/docker-buildx
$ chmod +x ~/.docker/cli-plugins/docker-buildx
$ docker buildx install
$ docker buildx versionThe final line of the output should show the installed Docker Buildx version, eg:
github.com/docker/buildx v0.8.2 266c0eac611d64fcc0c72d80206aa364e826758d
Before using a Docker-driven process an image needs to be created for the target architecture you're compiling for. This is the case even if you're using a Docker Buildx process targeting your native architecture.
The wrapper script create_image.py exists to guide the image creation process, including bringing in CMake from thirdparty. Provide the architecture identifier to that script to build an image.
eg. for ARMhf
$ ./create_image.py armhfCheck the Docker image list to verify it's been created
$ docker images lsAt this point you're ready to use the created image to build a library from thirdparty.
eg. to build Assimp for ARMhf change into that directory then run the following
$ rm -rf linux/armhf
$ docker buildx bake armhfThe build output will (for ARMhf) be deployed into linux/armhf. You may want to then change ownership to the normal user.
Useful options when running Buildx's bake include:
- Invalidate the cache:
--no-cache - Get plain log output:
--progress plain
Follow the instructions within build_tools/cross_arch_linux_packaging for a work-in-progress process to build for another Linux architecture using emulation.
Edit the DockerFile in the root of the third-party library to make changes to the instructions executed for the build. In most cases where there are no NAP-specific (downstream) changes to the library a new version of the library can be deployed by bumping the version in the Dockerfile and running the Buildx bake command (above).
The following can be run to recover disk space
$ docker system prune -fMore aggressively, to remove all images, containers, layers, etc:
$ docker system prune -faTo delete a single image
$ docker image rm <image_name>eg.
$ docker image rm nap-armhf-raspbian_buster