Publish a Linux nightly, and build it against an older glibc (or musl) — current Ubuntu 24.04 builds require glibc 2.38+

[logbie]

Summary

WFL publishes a Windows MSI nightly but no Linux artifact, so Linux users build from source (~25 min on a small box). I've stood up a nightly Linux builder, and in doing so hit a portability constraint worth recording: a binary built on Ubuntu 24.04 links against glibc 2.38/2.39 and will not run on older distributions.

$ ./wfl --version
./wfl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by ./wfl)
./wfl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.39' not found (required by ./wfl)

The same binary runs fine on Ubuntu 24.04. So any published Linux nightly built on a current runner is implicitly "Ubuntu 24.04 or newer" — which excludes Debian 12, Ubuntu 22.04, and most enterprise LTS distros still in wide use.

Suggestions (pick whichever fits the project's goals)

1. Build the release artifact against an older glibc — e.g. build in a Debian 12 or Ubuntu 22.04 container. Binaries built against an older glibc run on newer systems; the reverse is not true. Cheapest option, widest reach, no code change.
2. Ship a statically-linked x86_64-unknown-linux-musl build alongside the glibc one. Fully portable, no libc dependency at all. Some crates need attention under musl, but for a CLI/interpreter it's usually painless.
3. At minimum, document the floor — state the minimum glibc/distro in the release notes and in Docs/, so a user on Debian 12 gets an explanation rather than a linker error.

Related: this affects the WFL Foundation principle of being approachable — the first thing a new Linux user meets shouldn't be a glibc symbol error.

Environment

• wfl 26.7.37, built from main with cargo build --release --locked (rustc 1.97.0) on Ubuntu 24.04 x86_64
• Fails on: Debian-based image with glibc < 2.38

[logbie]

Assessment: confirmed, well-scoped — a real portability constraint plus a genuine gap (no published Linux artifact). Not a code bug; a release/CI + docs item. Verified against current main (56b5adb).

The premise checks out. nightly.yml produces artifacts only on windows-latest (the two ubuntu-latest jobs are check-for-changes and release, which just publishes) — so there is indeed no Linux nightly today, and Linux users build from source. And ci.yml builds/tests on ubuntu-latest, which is now Ubuntu 24.04 (glibc 2.39), so any binary a current runner produces carries the 2.38/2.39 floor you're seeing. The glibc direction is exactly as you state: build-old-run-new works, the reverse doesn't.

On the three options, with a repo-specific refinement:

1. Older-glibc build — and you don't even need a container. GitHub still offers the ubuntu-22.04 hosted runner (glibc 2.35). A Linux release lane that is simply runs-on: ubuntu-22.04 (rather than a Debian 12 container) is the cheapest possible version of your option 1: one line, no Dockerfile, and glibc 2.35 already covers Ubuntu 22.04+, Debian 12 (2.36), and RHEL/Alma/Rocky 9 (2.34). A container only earns its keep if you want to reach glibc 2.31/2.28 (Debian 11, RHEL 8).

2. musl is more attractive here than the generic caveat suggests. The usual musl blocker is openssl-sys/native-tls — and this repo doesn't have it: TLS is rustls/ring (grep of Cargo.lock shows ring, no openssl-sys/openssl/native-tls), and ring builds cleanly on x86_64-unknown-linux-musl. So a fully-static musl artifact is likely close to "add the target + a CI lane," giving a single binary that runs anywhere with zero libc floor. That makes option 2 a strong candidate for the widest-reach artifact, complementing (1) as the native-performance one.

3. Document the floor regardless. Docs/reference/supported-platforms.md already lists Linux (glibc) as Tier 1 but states no minimum glibc version — adding the floor there (and to the release notes) turns a GLIBC_2.39 not found linker error into an explained requirement. This should land independent of (1)/(2).

Where the change lives: a new Linux build job in .github/workflows/nightly.yml (mirroring the Windows job's build/test/artifact-upload, minus the WiX/MSI steps), plus teaching the release job to accept the Linux tarball(s) — it currently only downloads/publishes the .msi and .vsix. No interpreter/language code is touched, so this is backward-compatible by construction.

Suggested sequence: ship (3) now (one doc edit); add the ubuntu-22.04 glibc lane (1) as the near-term default Linux nightly; treat the musl static build (2) as a fast follow given ring makes it low-risk. Suggested labels: enhancement, ci, build, docs, linux. Cross-ref #610 (supported-platforms/Testing dimension).

Posted by the WFL repo warden (automated triage pass).