[PR #513] fix: use musl static linking to eliminate GLIBC dependency for Linux binaries #527

New issue

Open

opened 2026-03-02 04:13:53 +03:00 by kerem · 0 comments

kerem commented

2026-03-02 04:13:53 +03:00

Owner

Original Pull Request: https://github.com/git-ai-project/git-ai/pull/513

State: open
Merged: No

fix: use musl static linking to eliminate GLIBC dependency for Linux binaries

Summary

Addresses #509 — pre-built Linux binaries currently require GLIBC 2.29+ (built on ubuntu:20.04 / GLIBC 2.31), which breaks on CentOS 8, RHEL 8, Debian 10, and other older Linux systems.

Instead of lowering the GLIBC floor (which would require an EOL build image), this PR switches Linux release builds to musl static linking, producing fully self-contained binaries with zero GLIBC dependency.

Changes:

release.yml: Switch Linux build targets from x86_64-unknown-linux-gnu / aarch64-unknown-linux-gnu to their -musl equivalents. Docker build image changed from ubuntu:20.04 to ubuntu:22.04 (maintained). Install musl-tools instead of libssl-dev.
release.yml: Replace the old GLIBC version logging with a static-linking assertion — the release build will now fail if ldd reports the binary as dynamically linked.
install.sh: No functional changes (net diff is a cosmetic blank line).

Artifact names (git-ai-linux-x64, git-ai-linux-arm64) are unchanged — this is a drop-in replacement from the user's perspective.

Review & Testing Checklist for Human

musl build has NOT been tested end-to-end: PR CI does not exercise the release workflow (workflow_dispatch only). A dry-run release build (workflow_dispatch with dry_run: true) is strongly recommended before merging to confirm the musl build succeeds for both x64 and arm64.
rusqlite bundled SQLite compilation with musl: rusqlite compiles SQLite from C source using cc. Verify musl-gcc (from musl-tools) correctly compiles this on both x64 and arm64. This is the most likely build failure point.
Static linking verification pattern: The ldd output check uses grep -q 'not a dynamic executable\|statically linked'. Confirm this matches the actual ldd output for musl binaries on the Ubuntu 22.04 runner (the exact message can vary by ldd version).
Binary size and runtime behavior: musl static binaries are typically larger and use musl's allocator instead of glibc's. For a CLI tool this should be negligible, but worth a quick sanity check (run the binary, check --version, try a commit).

Recommended test plan:

Trigger a dry-run release build to confirm both x64 and arm64 musl builds succeed
Download the resulting binaries and verify with file <binary> (should say "statically linked") and ldd <binary> (should say "not a dynamic executable")
Test the binary on a system with old GLIBC (e.g., CentOS 8 / Debian 10) to confirm it runs

Notes

Link to Devin run: https://app.devin.ai/sessions/ca466e0eab5d40a0a4f8b365e6dfd7bc
Requested by: @svarlamov

**Original Pull Request:** https://github.com/git-ai-project/git-ai/pull/513 **State:** open **Merged:** No --- # fix: use musl static linking to eliminate GLIBC dependency for Linux binaries ## Summary Addresses #509 — pre-built Linux binaries currently require GLIBC 2.29+ (built on `ubuntu:20.04` / GLIBC 2.31), which breaks on CentOS 8, RHEL 8, Debian 10, and other older Linux systems. Instead of lowering the GLIBC floor (which would require an EOL build image), this PR switches Linux release builds to **musl static linking**, producing fully self-contained binaries with **zero GLIBC dependency**. **Changes:** 1. **`release.yml`**: Switch Linux build targets from `x86_64-unknown-linux-gnu` / `aarch64-unknown-linux-gnu` to their `-musl` equivalents. Docker build image changed from `ubuntu:20.04` to `ubuntu:22.04` (maintained). Install `musl-tools` instead of `libssl-dev`. 2. **`release.yml`**: Replace the old GLIBC version logging with a static-linking assertion — the release build will now fail if `ldd` reports the binary as dynamically linked. 3. **`install.sh`**: No functional changes (net diff is a cosmetic blank line). Artifact names (`git-ai-linux-x64`, `git-ai-linux-arm64`) are unchanged — this is a drop-in replacement from the user's perspective. ## Review & Testing Checklist for Human - [ ] **musl build has NOT been tested end-to-end**: PR CI does not exercise the release workflow (`workflow_dispatch` only). A dry-run release build (`workflow_dispatch` with `dry_run: true`) is **strongly recommended** before merging to confirm the musl build succeeds for both x64 and arm64. - [ ] **`rusqlite` bundled SQLite compilation with musl**: `rusqlite` compiles SQLite from C source using `cc`. Verify `musl-gcc` (from `musl-tools`) correctly compiles this on both x64 and arm64. This is the most likely build failure point. - [ ] **Static linking verification pattern**: The `ldd` output check uses `grep -q 'not a dynamic executable\|statically linked'`. Confirm this matches the actual `ldd` output for musl binaries on the Ubuntu 22.04 runner (the exact message can vary by `ldd` version). - [ ] **Binary size and runtime behavior**: musl static binaries are typically larger and use musl's allocator instead of glibc's. For a CLI tool this should be negligible, but worth a quick sanity check (run the binary, check `--version`, try a commit). **Recommended test plan:** 1. Trigger a dry-run release build to confirm both x64 and arm64 musl builds succeed 2. Download the resulting binaries and verify with `file <binary>` (should say "statically linked") and `ldd <binary>` (should say "not a dynamic executable") 3. Test the binary on a system with old GLIBC (e.g., CentOS 8 / Debian 10) to confirm it runs ### Notes - Link to Devin run: https://app.devin.ai/sessions/ca466e0eab5d40a0a4f8b365e6dfd7bc - Requested by: @svarlamov