fix(release): build static musl binaries for Linux artifacts

[mvanhorn]

Summary

Builds the Linux release artifacts against musl instead of glibc, so the published binaries are statically linked and run on distros older than the builder. Closes #503.

The Linux jobs built with cargo build --release on ubuntu-latest, producing binaries dynamically linked against that runner's glibc. Anyone on an older distro got a glibc version error rather than a working binary.

Changes:

• .github/workflows/release.yml: each matrix entry gains a build_target; Linux maps to the musl triple while macOS and Windows keep their existing target. Installs musl-tools, points the musl linker and CC at musl-gcc, builds with --target, and adds a verification step that runs --version on the produced binary and fails if readelf still shows an INTERP segment. The published artifact names are unchanged, so download URLs stay stable.
• Cargo.toml: git2 moves to target-conditional dependencies. Non-musl keeps the current default-features-off build; musl adds zlib-ng-compat, because the vendored zlib otherwise links against the host library and defeats the static build.
• Cargo.lock: picks up zlib-ng-compat's tree.
• .github/workflows/ci.yml: a musl build job so a change that breaks the static build fails in CI rather than at release time.
• RELEASE.md: note that Linux artifacts are static musl builds.

Validation

From a clean checkout of this branch:

cargo build           -> ok
cargo fmt --check     -> clean
cargo metadata        -> ok (target-conditional deps resolve)

I could not exercise the musl path locally; that needs a Linux runner with musl-tools, and I am on macOS. The parts I could not run are the ones the new CI job and the readelf INTERP check now cover, which is deliberate: the verification step is written to fail loudly on the runner rather than silently ship a dynamic binary again.

Worth your eye before merge:

1. x86_64-unknown-linux-gnu and aarch64-unknown-linux-gnu are kept as the artifact target names while building musl underneath. That preserves existing download URLs, but the filename now says gnu for a musl binary. If you would rather rename the artifacts and accept the URL break, that is a one-line change per matrix entry.
2. The libssl-dev/pkg-config install is replaced by musl-tools. Nothing in the current dependency tree needs OpenSSL (git2 is default-features-off), so this should be safe, but you know the tree better than I do.

AI was used for assistance.

[wcampbell0x2a]

I really don't think lying about the libc is a good idea.

[mvanhorn]

Fair point, dropped the gnu names in 4339ba2.

The matrix had a separate target field that existed only so the archives could keep their old -unknown-linux-gnu names while building against musl. That's gone; the artifact name now comes from build_target, so the Linux archives are x86_64-unknown-linux-musl and aarch64-unknown-linux-musl.

That does break the existing Linux download URLs, which is what the old naming was protecting. RELEASE.md is updated to match, including the checksum commands for the Homebrew formula. Flagging it in case the install script or tuicr update pin those URLs anywhere I haven't found.

[lllamnyp]

Thanks for picking up #503, this looks great!

[lllamnyp]

Thanks for taking #503.

I was testing out the build and found that running tuicr update replaces the statically linked binary with a dynamically linked one. Here is where this appears to be pinned:

tuicr/src/update/install/source.rs

Lines 28 to 29 in 4339ba2

	("linux", "x86_64") => "x86_64-unknown-linux-gnu",
	("linux", "aarch64") => "aarch64-unknown-linux-gnu",

Two things that might bite once this lands, though you'd know better than me: after a release that ships no gnu Linux archive, tuicr update on existing installs looks like it would fail outright rather than upgrade, since the asset is looked up by exact name. And the triple is baked in at compile time, so a fix landing in that same release wouldn't reach the binaries already installed.

[mvanhorn]

Good catch on both counts, thanks for actually running the built binary.

The release workflow now builds x86_64-unknown-linux-gnu and aarch64-unknown-linux-gnu alongside the musl targets, with -C target-feature=+crt-static so the gnu archives are statically linked too. musl-tools and the musl linker config are gated on the -musl suffix so the gnu jobs skip them.

That keeps the exact asset names existing installs look for, so tuicr update on a gnu install still resolves and now lands a static binary rather than swapping in a dynamic one.

The compile-time triple point stands: anything already installed keeps whatever triple it was built with, so this only takes effect from the next release onward. Nothing to do about already-shipped binaries short of a re-install, which seems acceptable given the alternative was update breaking outright.

[agavra]

We now rely on the official hombrew tap, I'm not sure if we need to change anything to get it to update after that. How are you intending to install the static binaries? Otherwise LGTM, I'm happy to merge it anyway.

[agavra]

CI failure is unrelated, rebasing on main should fix this.

[lllamnyp]

How are you intending to install the static binaries?

Seeing as I brought up the original issue, I'll answer this. I usually prefer to install them by directly downloading them from GitHub's releases. The pipe-curl-to-shell approach also appears to be doing more or less the same thing. I don't think much if anything would change, regardless of install method.

[mvanhorn]

Rebased onto main at 08aa4e9, so the unrelated CI failure should be gone. cargo check is clean and both workflow files still parse.

@lllamnyp thanks, that settles it. Direct download from the releases page is what the static musl artifacts are built for, and the curl-to-shell path pulls the same archives, so neither install method needs anything extra here.