## Problem The released orbit Linux binary requires **GLIBC ≥ 2.34** and **GLIBCXX ≥ 3.4.30** (GCC 12+ libstdc++). It fails to run on RHEL/UBI 8 (GLIBC 2.28) and even on UBI 9 minimal (GLIBCXX 3.4.29 — GCC 11). The C++ ABI gap is the real blocker, not glibc — it comes from `duckdb-client/bundled`, where DuckDB is compiled from C++ and dynamically linked against the build host's libstdc++ (Debian Bookworm, GCC 12). This blocks `orbit local` in Duo Workflow workload containers. The default image (`registry.gitlab.com/gitlab-org/duo-workflow/default-docker-image/workflow-generic-image:v0.0.6`) is RHEL 8 based, and the hardened UBI 9 image also fails today: ```text $ docker run --rm -v /tmp/orbit-test:/work \ registry.gitlab.com/gitlab-org/duo-workflow/default-docker-image/workflow-generic-image:v0.0.6 \ /work/orbit --version /work/orbit: /lib64/libc.so.6: version `GLIBC_2.34' not found /work/orbit: /lib64/libgcc_s.so.1: version `GCC_12.0.0' not found /work/orbit: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found /work/orbit: /lib64/libstdc++.so.6: version `CXXABI_1.3.13' not found ``` Full research and verification: https://gitlab.com/gitlab-org/orbit/knowledge-graph/-/snippets/5994579 ## Proposal Mirror the Windows build's static-linking flags to the Linux build. The Windows job in `.gitlab/ci/release-local.yml` already sets: ```yaml RUSTFLAGS: "-C link-arg=-static-libgcc -C link-arg=-static-libstdc++" ``` Adding the same `RUSTFLAGS` to `.local-cli-build-linux` statically links libstdc++ and libgcc into the binary, eliminating the host libstdc++/libgcc dependency. Glibc is still linked dynamically, but the GLIBCXX/CXXABI/GCC gap disappears. After this change, orbit runs on **any glibc ≥ 2.34 system** regardless of libstdc++ vintage — UBI 9 minimal, Bookworm, Ubuntu 22.04+, etc. ```diff .local-cli-build-linux: extends: - .job-template - .sccache-template - .local-cli-release-rules stage: build needs: [] variables: PLATFORM: linux + RUSTFLAGS: "-C link-arg=-static-libgcc -C link-arg=-static-libstdc++" script: - ./scripts/build-local-cli.sh ``` ## Scope - One-line change in `.gitlab/ci/release-local.yml`. - Binary size increases ~2-3 MB. - No behavior change, no source-code change, no new target triple. ## Acceptance criteria - `ldd target/x86_64-unknown-linux-gnu/release/orbit` shows no `libstdc++.so.6` or `libgcc_s.so.1` dependency. - Binary runs on UBI 9 minimal (`registry.access.redhat.com/ubi9-minimal`) without `GLIBCXX_3.4.30 not found` errors. - `local-cli-build-linux-amd64` and `local-cli-build-linux-arm64` jobs pass on CI. ## Follow-up For environments below glibc 2.34 (RHEL 8, Ubuntu 20.04, air-gapped/scratch containers), a fully static musl binary is the long-term answer — tracked separately in #769 so this immediate fix can land independently. <!-- This issue captures the immediate, low-risk fix. The musl follow-up is the gold-standard "runs anywhere" solution but introduces real porting work for bundled DuckDB. -->