feat(ci): build and ship glibc (gnu) binaries via cross#244
Open
sksat (sksat) wants to merge 2 commits into
Open
feat(ci): build and ship glibc (gnu) binaries via cross#244sksat (sksat) wants to merge 2 commits into
sksat (sksat) wants to merge 2 commits into
Conversation
Distribute dynamically linked glibc binaries for x86_64 and aarch64 alongside the existing musl (static) ones, so users on glibc systems can take a native build. A new `build_gnu` job builds these targets with `cross` rather than a bare `cargo build`: cross's *-unknown-linux-gnu images are Ubuntu 20.04 based (glibc 2.31), so the binaries stay runnable on older distros. Building natively on the ubuntu-24.04 runner would instead bake in its glibc 2.39 symbols and silently produce binaries that won't start on anything older. The musl build stays a native cargo build. scripts/verify-release-binary.sh guards against that failure mode: it asserts each binary's linkage (gnu dynamic), smoke-runs the host-arch ones (--help), and enforces a glibc-2.31 floor on the required symbol versions so a non-portable build fails the release rather than shipping. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sksat (sksat)
force-pushed
the
feat/cross-glibc-build
branch
from
e39e5d5 to
902e13a
Compare
Add the verification step to the musl `build` job too (it was only on the new gnu job), so the static binaries we ship are guarded the same way. While wiring it up, found the linkage check only matched "statically linked"; modern rustc emits static-PIE musl binaries that `file` reports as "static-pie linked", which the check rejected. Assert the real invariant instead — a musl binary carries no dynamic loader — so both spellings pass while a dynamically linked binary still fails. Also link the CHANGELOG entry to the PR. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Distribute dynamically linked glibc binaries for
x86_64andaarch64alongside the existing musl (static) ones. The musl build is unchanged.Why / how
A new
build_gnujob builds the gnu targets withcrossrather than a barecargo build. cross's*-unknown-linux-gnuimages are Ubuntu 20.04 based (glibc 2.31), so the binaries stay runnable on older distros. Building natively on theubuntu-24.04runner would instead bake in its glibc 2.39 symbols and silently produce binaries that won't start on anything older.Only the gnu targets go through cross; the musl build stays a native
cargo buildwith the apt-installedmusl-tools/ aarch64 linker.kble-serialportbuilds cleanly under cross becauseserialport 4.9usesnix(sysfs) on Linux, not libudev — no extra C libs needed in the image.TDD / guard
scripts/verify-release-binary.shis the test that captures the intended behavior, run from thebuild_gnujob over every produced binary:--helpon the host-arch (x86_64) binaries; structurally checks the aarch64 ones (can't execute on an x86_64 runner).GLIBC_x.ysymbol version must be ≤ 2.31, so a non-portable build fails the release instead of shipping.The floor discriminates exactly between a cross build (≤2.31, passes) and a native modern build (~2.39, fails). It's tunable via
--glibc-floor/ the script'sDEFAULT_GLIBC_FLOORif a target needs a different floor.Validation
The actual
crossbuild can only be exercised in CI (no local container engine). This PR touches.github/workflows/release.yml, which is in the workflow'spull_requestpath filter, so opening it runsbuild_gnuend-to-end (build → verify) on Actions.🤖 Generated with Claude Code