Skip to content

Add x86_64-unknown-linux-musl target to CI#8199

Open
joseph-isaacs wants to merge 7 commits into
developfrom
claude/elegant-ptolemy-VxJVN
Open

Add x86_64-unknown-linux-musl target to CI#8199
joseph-isaacs wants to merge 7 commits into
developfrom
claude/elegant-ptolemy-VxJVN

Conversation

@joseph-isaacs
Copy link
Copy Markdown
Contributor

Summary

This PR adds a new CI job to build and test the Vortex codebase against the x86_64-unknown-linux-musl target. This ensures compatibility with musl-based Linux distributions and validates that the codebase can be compiled with the musl C toolchain.

The new job:

  1. Adds a matrix configuration for the musl target with appropriate exclusions for CUDA-related crates (which don't have musl targets)
  2. Installs the musl target and musl-tools via rustup and apt
  3. Configures the Rust build to use musl-gcc as the C compiler and linker for cross-compiled C dependencies

This complements the existing wasm32 target build and ensures broader platform compatibility.

Testing

The change is validated by the CI workflow itself—the new job will run on every commit and verify that the codebase builds successfully for the musl target with all default features enabled (excluding CUDA crates as appropriate).

https://claude.ai/code/session_01Rv3Ehw978URWYRPZ9r12FH

Cross-compile the default-feature workspace for x86_64-unknown-linux-musl
on the Ubuntu runners, installing musl-tools and using musl-gcc for C deps
and linking. CUDA crates are excluded as they have no musl target.

This verifies vortex builds for musl ahead of enabling the linux_amd64_musl
DuckDB extension build in duckdb-vortex.

Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
@joseph-isaacs joseph-isaacs added the changelog/skip Do not list PR in the changelog label Jun 1, 2026
@0ax1 0ax1 self-requested a review June 1, 2026 15:55
@codspeed-hq
Copy link
Copy Markdown

codspeed-hq Bot commented Jun 1, 2026

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚡ 1 improved benchmark
❌ 1 regressed benchmark
✅ 1273 untouched benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

Mode Benchmark BASE HEAD Efficiency
Simulation chunked_varbinview_canonical_into[(1000, 10)] 162.1 µs 198 µs -18.12%
Simulation chunked_varbinview_canonical_into[(100, 100)] 309.2 µs 273.2 µs +13.16%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.


Comparing claude/elegant-ptolemy-VxJVN (bd0e8c5) with develop (326b475)

Open in CodSpeed

joseph-isaacs and others added 6 commits June 1, 2026 16:09
Plain musl-gcc can't cross-compile C++ deps (e.g. custom-labels) because
musl-tools ships no musl-g++, so use cargo-zigbuild with zig as the C/C++
toolchain instead. Move the musl build out of the build-rust matrix into a
dedicated job since it needs a different build command and zig setup.

Exclude vortex-duckdb and its dependents: their build.rs has no prebuilt
DuckDB for musl, so they can't build standalone. The DuckDB extension builds
vortex-duckdb against a musl DuckDB it compiles itself.

Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
Cross-compiling the workspace to musl from the glibc host is not viable:
musl-tools ships no musl-g++ for C++ build deps (custom-labels), and zig's
linker rejects the --dynamic-list arg those deps emit. Build natively inside
an Alpine container instead, which has a real musl gcc/g++ and GNU ld.

Checkout stays on the host because JS actions can't run in a musl container.
CUDA crates and vortex-duckdb (and dependents) are excluded: the former have
no musl target, the latter's build.rs has no musl DuckDB and is exercised by
the DuckDB extension build instead.

Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
The custom-labels crate (transitive dep of vortex-io) runs bindgen
unconditionally in its build script. In a fully static musl build the
build-script binary cannot dlopen libclang, panicking with 'Dynamic
loading not supported'. Disabling crt-static links the build scripts
dynamically so libclang loads.

Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
Split the x86_64-unknown-linux-musl test job out of the unified
rust-test-other matrix into a dedicated .github/workflows/musl.yml so
its container-based, hand-provisioned execution model is no longer
coupled to the glibc test runners. The check name 'Rust tests
(linux-musl)' is unchanged.

Add tzdata to the Alpine package set: without /usr/share/zoneinfo the
datetime tests fail with 'failed to find time zone UTC since there is no
time zone database configured' (38 failures).

Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The musl container bind-mounts the host runner's checkout at /work, owned
by a different uid than the container root. git then rejects it as
'dubious ownership' and 'git rev-parse HEAD' returns empty. vortex-bench
(GIT_COMMIT_ID) and the benchmarks website (build.rs VORTEX_BENCH_BUILD_SHA)
embed that SHA in insta snapshots, redacted to <commit-sha>/<build-sha>; an
empty SHA breaks the redaction and fails 10 snapshot tests. Marking /work
safe lets git resolve the SHA so the snapshots match.

Signed-off-by: Joe Isaacs <joe.isaacs@live.co.uk>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

changelog/skip Do not list PR in the changelog

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants