Ship prebuilt binaries in GitHub Releases

Building Vx from source requires an exact LLVM major version and a handful of system libraries, and the five issues filed today (#363–#367) all came out of doing it twice. Most people who want to try the language should not have to do any of it.

Why this is worth doing

• The LLVM pin is exact. mlir-sys = "220.0.2" means LLVM 22 and nothing else. Ubuntu's own repositories lag it, so scripts/setup_linux.sh has to add apt.llvm.org. A wrong major version fails at link time with undefined MLIR C-API symbols, which is not a self-explaining error.
• The build is not small. target/ reaches 2.0 GB for a release build; 1m48s on 36 vCPU, considerably longer on a laptop.
• The install has sharp edges. A clean cargo build --release currently produces a compiler that cannot run anything (#364), and setup.sh could not find LLVM on Linux at all until today (#365).

What a release artifact has to contain

vxc is not self-contained, and this is the part that needs deciding rather than assuming.

Shipped alongside the binary:

• libvx_std_core.{so,dylib} — the JIT dlopens it at run time (#364). A vxc without it links every program and then fails.

Required on the target machine, at run time:

So a "binary release" removes the build dependency on LLVM but not the runtime one — mlir-translate still has to be LLVM 22. That should be stated plainly in the release notes rather than discovered.

Feasibility differs sharply by platform

Measured on the two supported targets:

Linux x86_64 — straightforward. 230 MB binary; LLVM and MLIR are statically linked. The only non-system dynamic dependencies are:

libz.so.1
libzstd.so.1

Both are present on any mainstream distribution.

macOS arm64 — needs work first. 285 MB binary, and it hard-links Homebrew prefixes:

/opt/homebrew/opt/z3/lib/libz3.4.15.dylib
/opt/homebrew/opt/zstd/lib/libzstd.1.dylib

Shipping that as-is produces a binary that fails on any Mac without Homebrew and those exact formula versions. It needs either static linking of z3/zstd or install_name_tool rpath rewriting plus bundled dylibs, and then notarisation to avoid Gatekeeper prompts.

Proposal

1. Start with linux-x86_64, where the work is packaging rather than engineering. Tarball: vxc, libvx_std_core.so, fleet/, a README naming the three runtime tools.
2. Add a vxc --check-toolchain that reports the three runtime tools and their versions, and says what is missing. Cheap, and useful for source builds too.
3. Tackle macos-arm64 separately once the dylib paths are resolved — it is a different problem, not the same one on another OS.
4. Attach artifacts on tag via CI.

The Docker image proposed alongside this covers the Linux case for people who would rather not think about the runtime tools at all.

Start with the Linux x86_64 proposal, the existing cargo build --release, scripts/setup_linux.sh, and the runtime references in src/jit.rs:161, src/hir/seam.rs, and src/hir/prover.rs. Define the tagged CI artifact as a tarball containing vxc, libvx_std_core.so, fleet/, and a README, then verify the three runtime tools and their versions; keep macOS arm64 separate until its dylib paths are resolved.