release: the x86_64-unknown-linux-gnu binary needs GLIBC 2.38 — won't load on ubuntu-22.04 (a supported GitHub runner)

[avrabe]

loom-v1.2.0-x86_64-unknown-linux-gnu.tar.gz does not load on ubuntu-22.04, which is still a supported GitHub Actions runner image:

loom: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by loom)
loom: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.31' not found (required by loom)

ubuntu-22.04 ships GLIBC 2.35. The binary requires 2.38, so it fails at load time — before --version can run.

How we hit it

Standing up a CI gate that runs the meld → loom → synth chain. The install step succeeded (download + checksum verify + extract + install -m755), and the failure surfaced only when the job tried loom --version.

Worth noting for triage: meld v0.41.3 loaded fine on the same runner in the same job, so this isn't the fetch-a-pinned-binary approach — it's specific to loom's build environment.

Why it's worth fixing rather than documenting

• It fails as a dynamic-linker error, not a usable message. Nothing points at "your runner is too old" or "use 24.04" — a consumer sees an unresolved-symbol dump for a binary they just successfully downloaded and checksummed.
• x86_64-unknown-linux-gnu reads as the portable Linux artifact. There's no hint at the download that it carries a floor of GLIBC 2.38.
• It's the obvious install path — release binary + checksum — so it's likely to hit anyone wiring loom into CI on a 22.04 image.

Suggestions, roughly in order of preference

1. Build releases on an older base (a 20.04/22.04 container, or cargo-zigbuild / a manylinux-style toolchain) so the artifact runs on the oldest reasonably supported distro. This is what most projects do and it costs nothing at use time.
2. Ship a statically linked x86_64-unknown-linux-musl artifact alongside, for consumers who want zero GLIBC coupling.
3. At minimum, state the GLIBC floor in the release notes and asset naming, so the failure is predictable rather than discovered at load.

What we did meanwhile

Pinned our job to ubuntu-24.04 (GLIBC 2.39, GCC 13 → GLIBCXX 3.4.32), which resolves it on our side. Not urgent for us; filing because the next consumer will hit the same wall with the same unhelpful error, and because the fix belongs in the release build rather than in every consumer's workflow.

Happy to test a candidate artifact against 22.04 and 24.04 — it's a one-line change in our workflow to try both.

[avrabe]

Confirmed and fixed in #312 (v1.3.0). Thanks — the report was exactly right, including the part about it being loom-specific rather than an artifact-fetch problem.

Reproduced from the shipped artifact rather than taken on report:

GLIBC_2.38          # max required
GLIBCXX_3.4.31      # max required

Cause: the x86_64-unknown-linux-gnu job ran on ubuntu-latest, so the binary's floor silently tracked GitHub's newest image. Nothing pinned it and nothing checked it.

Fix (your option 1, plus a gate): pinned to ubuntu-22.04 and the floor is now asserted after the build — the release fails if the binary needs more than GLIBC 2.35 / GLIBCXX 3.4.30. A pin with only a comment is not enough: a dependency bump re-floated our cranelift-isle pin the same way last week, past a comment that explained exactly why not to. So the invariant is machine-checked, not documented.

On option 2 (musl): the honest blocker is that the libstdc++ requirement exists only because loom links Z3, which is C++. Static musl + Z3 is the unpleasant corner of that toolchain, so shipping a musl artifact today would mean carrying that fight indefinitely. We're instead retiring Z3 in favour of our pure-Rust solver — filed as #313. That removes the C++ dependency entirely, at which point musl-static is close to free and this failure mode stops existing rather than being pinned around. Your report is cited there as one of the reasons to prioritise it.

On option 3: the CHANGELOG for v1.3.0 states the floor explicitly.

Taking you up on the offer to test — once #312 lands I'll ping you with the built artifact so you can run it against 22.04 and 24.04 before I tag. That's better evidence than my assertion step, since it exercises the real consumer path you hit.