feat(local): add musl target for fully static Linux binary

Problem

Even with statically-linked libstdc++/libgcc (the immediate fix), the orbit Linux binary still dynamically links glibc and pins consumers to glibc ≥ 2.34. This is fine for UBI 9, Bookworm, and Ubuntu 22.04+, but doesn't cover:

  • RHEL/UBI 8 hosts (glibc 2.28) and older enterprise distros
  • Alpine and other musl-based base images
  • scratch / distroless containers
  • Air-gapped / self-managed environments where customers choose their own host

For comparison, glab runs everywhere because it's a Go binary — Go statically links its runtime and uses no libc-versioned symbols. That's the property orbit lacks. The general industry pattern for Rust CLIs distributed broadly (ripgrep, fd, bat, rustup, etc.) is -unknown-linux-musl static binary.

Proposal

Add x86_64-unknown-linux-musl and aarch64-unknown-linux-musl build targets to the orbit local CLI release pipeline. This produces a fully statically linked binary with zero host dependencies — file orbit would report statically linked.

Challenges

  • Bundled DuckDB. The duckdb-client/bundled feature compiles DuckDB from C++ source. Cross-compiling C++ against musl needs a musl C++ toolchain (musl-tools + g++-x86-64-linux-musl, or a dedicated builder image). May need patches or a musl-compatible DuckDB build.
  • Native deps. Crates with C dependencies (openssl, ring, zstd, …) need vendored / static features verified one by one.
  • sccache integration. The existing .sccache-template may need adjustments for musl targets.
  • CI build matrix. Adds 2 more jobs (amd64 + arm64 musl) on top of the existing gnu builds.
  • Performance. musl's malloc is slower than glibc's; usually mitigated by linking mimalloc or jemalloc. Worth benchmarking the indexer hot path before/after.

Tip: @bohdanpk has had success building this with cargo-zigbuild — worth trying as the first approach, since zig's bundled toolchain handles musl cross-compilation (including C/C++ deps) out of the box.

Acceptance criteria

  • file target/x86_64-unknown-linux-musl/release/orbit reports statically linked.
  • Binary runs on Alpine, scratch, UBI 8, and any Linux ≥ kernel 3.2 without LD_LIBRARY_PATH shenanigans.
  • Indexer hot-path benchmarks do not regress beyond an agreed threshold (TBD during implementation).
  • musl jobs added to .gitlab/ci/release-local.yml, with artifacts published alongside the gnu builds.

Context

This is the long-term, "fire and forget" answer for orbit's Linux distribution. The immediate unblocker for Duo Workflow workload containers (UBI 9 / Bookworm hosts) is tracked in #768 (closed) and lands first — it's a one-line RUSTFLAGS change with no porting work. This issue picks up once there's pressure from customers on older glibc, air-gapped enterprise, or a desire to ship orbit in scratch/distroless images.

Not urgent; follow-up to the static-libstdc++ fix.

Edited by Dmitry Gruzd