The constraint
The release binaries are compiled on a GitHub runner and copied into a distroless base rather than compiled inside the image. glibc symbol versioning is forward-compatible only, so the binary must be built against a glibc no newer than the base's, or it links cleanly and dies at exec time.
That makes the runner OS load-bearing, and it has to be pinned — a floating ubuntu-latest would break the image the day GitHub rolls it forward, with a green build and no failure until something tries to run it.
The awkward part isn't the pin itself, it's the direction of the coupling: the base image dictates how new the build environment is allowed to be.
What would fix it
cargo-zigbuild targets an explicit glibc version (--target x86_64-unknown-linux-gnu.2.36) regardless of what the host has. Zig ships a bundled clang plus stub definitions of glibc across many versions, so the build never links against the runner's glibc at all.
With that, the runner can float and the binary still runs on any base at or above the chosen floor. It also lowers the floor on the published tarballs, which matters for anyone installing them outside a container.
Why this isn't obviously worth doing
cargo-zigbuild is 0.x and tracks Zig, which is itself pre-1.0 and makes breaking changes. Adopting it means pinning the Zig version in CI and absorbing that churn.- Its rough edges are LTO,
-sys crates and prebuilt C/C++ blobs — which is close to this repo's exact shape, given lto = true, codegen-units = 1 and pdfium.
- Partially mitigating:
bundled-pdfium embeds the library with include_bytes!, so at build time it is data rather than a link target. The native linking that remains is small.
Evaluating it
--version is not sufficient evidence that a zigbuild-produced binary is good. PDF extraction is the path that would break, because it depends on the embedded pdfium being extracted and dlopened at runtime — which no build-time check covers. Any trial needs to exercise that on both architectures.
Worth comparing against the cheaper alternative: building on the oldest supported runner achieves a low glibc floor with no new tooling, at the cost of an old build environment. Zigbuild's distinct advantage is having a new runner and an old floor, so the question is whether that combination is worth the dependency.
Not urgent
Nothing is blocked. The current pin is a supported LTS with years left, and the next Debian release raises the base's glibc, which lifts the ceiling on its own. This is worth doing when the pin actually bites — or if the glibc floor on the published tarballs becomes a complaint.
The constraint
The release binaries are compiled on a GitHub runner and copied into a distroless base rather than compiled inside the image. glibc symbol versioning is forward-compatible only, so the binary must be built against a glibc no newer than the base's, or it links cleanly and dies at exec time.
That makes the runner OS load-bearing, and it has to be pinned — a floating
ubuntu-latestwould break the image the day GitHub rolls it forward, with a green build and no failure until something tries to run it.The awkward part isn't the pin itself, it's the direction of the coupling: the base image dictates how new the build environment is allowed to be.
What would fix it
cargo-zigbuildtargets an explicit glibc version (--target x86_64-unknown-linux-gnu.2.36) regardless of what the host has. Zig ships a bundled clang plus stub definitions of glibc across many versions, so the build never links against the runner's glibc at all.With that, the runner can float and the binary still runs on any base at or above the chosen floor. It also lowers the floor on the published tarballs, which matters for anyone installing them outside a container.
Why this isn't obviously worth doing
cargo-zigbuildis 0.x and tracks Zig, which is itself pre-1.0 and makes breaking changes. Adopting it means pinning the Zig version in CI and absorbing that churn.-syscrates and prebuilt C/C++ blobs — which is close to this repo's exact shape, givenlto = true,codegen-units = 1and pdfium.bundled-pdfiumembeds the library withinclude_bytes!, so at build time it is data rather than a link target. The native linking that remains is small.Evaluating it
--versionis not sufficient evidence that a zigbuild-produced binary is good. PDF extraction is the path that would break, because it depends on the embedded pdfium being extracted and dlopened at runtime — which no build-time check covers. Any trial needs to exercise that on both architectures.Worth comparing against the cheaper alternative: building on the oldest supported runner achieves a low glibc floor with no new tooling, at the cost of an old build environment. Zigbuild's distinct advantage is having a new runner and an old floor, so the question is whether that combination is worth the dependency.
Not urgent
Nothing is blocked. The current pin is a supported LTS with years left, and the next Debian release raises the base's glibc, which lifts the ceiling on its own. This is worth doing when the pin actually bites — or if the glibc floor on the published tarballs becomes a complaint.