qmcgaw/binpot repository overview

⁠Binpot

The statically compiled, cross architecture, Docker based, binaries pot.

Blog post⁠

⁠Usage

The usage is focused to build other Docker images.

For example:

FROM alpine:3.14
COPY --from=qmcgaw/binpot:helm /bin /usr/local/bin/helm

🔍 Search for all image tags 💡⁠

• The Docker image tags for qmcgaw/binpot follow the following formatting:
  • :name for the latest stable version of the program name
  • :name-v0.0.0 for the semver version of the program name
• Each Docker image is based on scratch⁠ and only contain the binary program at the path /bin.
• Each Docker image and binary program is built for each of the possible CPU architecture supported by Docker, unless indicated otherwise.
• Each binary has permissions 500 (read and execute for the user owner)
• You can change the ownership in the COPY command using --chown=1000 for example, without duplicating the binary in your Docker image layers.
• Each Docker image has an entrypoint [ "/bin" ] so you can run it as well

Need help? ▶️ Create a discussion⁠

Thinking of copying the binary for your host?⁠

⁠Programs available

ℹ️ all architectures means: linux/amd64, linux/386, linux/arm64, linux/arm/v7, linux/arm/v6, linux/ppc64le, linux/s390x, linux/riscv64

Want more!? ▶️ Create an issue!⁠

⁠How it works

1. For each program, a Dockerfile describes how to build it. The final binary is placed on a final scratch⁠ based Docker image. Example: helm has ./dockerfiles/helm/Dockerfile⁠
2. For each program, a Github Action workflow is triggered when its Dockerfile or the workflow itself is changed. This workflow takes care of:
   1. Cross build the program for all CPU architectures
      • If one architecture is not supported such as for dlv, build the unavailable⁠ program
   2. Pushing the images containing the program to Docker Hub and ghcr.io

⁠Note on dlv

💁 Concerning dlv: all images are built for all architectures even if the program does not support all of them. A substitute Go program printing dlv v1.7.0 is unavailable on <platform name> and exiting with exit code 1 is used for unsupported platforms. This is like so so you can still cross build with all the architectures, especially if the program is an optional dependency. This is often the case for VSCode development containers for instance. In this case, if you try to build for arm/v7 and need dlv as an optional dependency, your COPY --from=qmcgaw/binpot:dlv will not fail.

⁠Notes on Rust programs

💁 Cross compiling Rust needs a C cross compiler as soon as the program links C code, which happens through crates such as tikv-jemalloc-sys. The Dockerfiles use cargo-zigbuild⁠ with the zig Alpine package as C cross compiler and linker, which still gives fully static binaries (musl) on every architecture. See dockerfiles/rumdl⁠ as a reference.

⚠️ For Podman, Zig compiles musl from source for each target, which needs more than the 1024 file descriptors that podman build allocates (soft and hard limit, so it cannot be raised from the Dockerfile). Therefore build with podman build --ulimit nofile=65536:65536 dockerfiles/<program> or the link step fails with error: sub-compilation of musl libc.a failed.

🔧 On the 32 bits Arm targets (linux/arm/v6 and linux/arm/v7), the compiler flags that rustc passes to the C compiler are not understood by zig, so the C dependencies are built through zig-cc-wrapper.sh⁠, which rewrites them for zig. It keeps the exact same architecture baseline as rustc uses (-mcpu=generic+v7a and -mcpu=generic+v6 in zig syntax).

🧭 Each Dockerfile carries its own copy of that wrapper: the build context of a program is its own directory, so a file cannot be COPYd from another program.

⁠Note on rumdl

rumdl is the first Rust program of this repository, and links jemalloc⁠. Upstream only publishes amd64 and arm64 binaries, so the six other architectures are built here, and all eight tags exist:

• jemalloc bakes the page size at build time, so JEMALLOC_SYS_WITH_LG_PAGE is 12 on amd64, 386, arm/v6 and arm/v7, and 16 on arm64, ppc64le and riscv64: it has to be greater than or equal to the page size of the systems running the binary, and 16 covers the 16 KiB page systems of Asahi Linux and Raspberry Pi 5 as well as the 64 KiB page kernels.
• linux/s390x gets the unavailable⁠ substitute program, printing rumdl vX.Y.Z is unavailable on linux/s390x and exiting with 1, because no static binary is possible there:
  • there is no s390x musl Rust target, so the C standard library has to be glibc on this architecture;
  • zig can link a static glibc for most architectures but explicitly rejects s390x, and a dynamically linked glibc binary cannot run on a scratch⁠ image.

A real linux/s390x build would require the s390x-unknown-linux-gnu Rust target with the Debian toolchain gcc-s390x-linux-gnu (CC_s390x_unknown_linux_gnu=s390x-linux-gnu-gcc), producing a dynamically linked binary, which is out of the scope of this repository.

⁠Copy the binary on your host

If you want to use the binary directly on your host, you can do it with Docker. This has the advantage that it will automatically get the right binary for your host platform.

In the following we want to install helm on our host.

For example:

export PROGRAM="helm" && \
  docker pull "qmcgaw/binpot:$PROGRAM" && \
  containerid="$(docker create qmcgaw/binpot:$PROGRAM)" && \
  docker cp "$containerid:/bin" "/usr/local/bin/$PROGRAM" && \
  docker rm "$containerid"

Test Helm works with helm

⁠TODOs

• Change version of go-outline once a release tag is made: Github issue⁠