build: ship static musl release binaries instead of glibc-linked ones - #2
Merged
Conversation
The published -gnu artifacts are built on ubuntu-24.04 and require GLIBC_2.39, so they cannot start on Ubuntu 22.04 (2.35), Debian 12 (2.36) or RHEL 9 (2.34) -- most current LTS targets. The failure is quiet. The binary installs, `command -v` finds it, and only the loader rejects it, so `--version` returns a linker error rather than a version string. A harness that verifies the installed build by reading --version cannot tell that apart from "wrong version" and reports the tool unavailable; the benchmark then skips and the overall run stays green. Observed exactly that: five suites skipped on a jammy host, CI green, nothing measured. Switches both targets to *-unknown-linux-musl. Static linking removes the glibc floor entirely, which for a benchmark binary that gets copied onto whatever host is under test is the property that actually matters -- the target distro is the one variable you do not control. Viable here because TLS is rustls with webpki-roots rather than OpenSSL, so there is no C TLS dependency and no reliance on the host's ca-certificates either. musl-tools is installed because rustls pulls in `ring`, which compiles C and assembly. Also adds an assertion that the artifact carries no GLIBC_* symbol versions, and fails the build if it does. The existing verification runs the binary on the build host, which is the one place it is guaranteed to work -- a passing smoke test there says nothing about older hosts, which is how this shipped. Asset names change from *-gnu to *-musl accordingly. Refs #1
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
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.
Fixes #1.
The published
-gnuartifacts are built onubuntu-24.04and requireGLIBC_2.39, so they cannot start on most current LTS targets:Why it went unnoticed
The failure is quiet. The binary installs,
command -vfinds it, and only the loader rejects it — so--versionreturns a linker error rather than a version string. A harness that verifies the installed build by reading--versioncan't distinguish that from "wrong version", reports the tool unavailable, and the benchmark skips while the run stays green.That's exactly what happened: five benchmark suites skipped on a jammy host, CI green, nothing measured.
The existing verification step runs the binary on the build host — the one machine where it's guaranteed to work. A passing smoke test there says nothing about older hosts, which is how this shipped.
The change
Both targets move to
*-unknown-linux-musl. Static linking removes the glibc floor entirely, which for a benchmark binary copied onto whatever host is under test is the property that actually matters — the target distro is the one variable you don't control.Viable here because TLS is rustls + webpki-roots, not OpenSSL: no C TLS dependency, and no reliance on the host's
ca-certificateseither.Also adds an assertion that the artifact carries no
GLIBC_*symbol versions, failing the build if it does — so this can't silently regress.Verified locally
Built
resque-benchforx86_64-unknown-linux-muslfrom this branch's config:Two notes for review
*-gnu→*-musl. v0.1.0 is days old so I doubt anything pins the old names, but it is a rename.musl-toolsmay be unnecessary. My local build succeeded withoutmusl-gcc. I've kept the install step becausering(pulled in by rustls) compiles C and asm and can need it under other toolchain configurations — but if you'd rather not pay the apt-get, it can likely go.