Module artifact 

What this release pins: one sysroot artifact per target, by URL and by hash.

Design: spec/cross-compile/13-distribution.md section 13.2, which says every downloaded artifact has a hash pinned in the rucc release, checked before use, with a mismatch being a hard failure and no flag to get past it. Section 13.8 divides the work in three and the other two are written: rucc_driver::fetch moves the bytes with a program the machine already has, and rucc_driver::install decides whether what arrived is the right tree. This is the third, which is the statement of what the right one is, and it is the half that makes the other two mean anything.

Why it is here rather than with the two halves that use it

Because it is read by something that cannot depend on the driver. The distribution manifest of section 13.5 is generated by a build tool, the same way docs/TARGETS.md and tests/link-lines are, and what it says about a target is what this table says plus what crate::Wall says. A build tool that pulled in the whole driver to read three strings would be a layer violation dressed up as convenience. It sits well here for a second reason as well: a pin is a fact about a sysroot, which is what this crate is for, and the fetch and the install are what a driver does with one.

Why the table is in the binary

Because a hash that travels with the artifact is not a pin, and a hash in a file beside the compiler is a hash whoever replaces the artifact can replace too. The release is the authority for what an artifact of that release is, so the table is compiled into the release, which also means an upgrade can change a URL without anything on the machine having to be told.

It is a table rather than a computed URL for the same reason. A name built out of a version and a tuple looks tidier and quietly says that every target’s artifact is at a predictable address forever, which is a promise about somebody else’s file server. A row per target costs three strings and says only what is true.

What is in it

Fifteen rows, which are the three windows-gnu targets, four musl ones and eight glibc ones. For windows-gnu, bin/mingw-headers in tamnd/rucc-cross installs mingw-w64 14.0.0’s headers, bin/mingw-runtime builds the runtime and the import libraries into the lib directory beside them, bin/artifact packs the tree, and the release sysroots-2026-09-21 is where the files are. The archives are 15.2 MiB for x86_64, 14.8 MiB for i686 and 12.5 MiB for aarch64, installing to 134 MB, 128 MB and 113 MB. The header half is the same 1702 files in all three, because mingw-w64 has no per architecture split and crate::Sysroot::splits_by_arch says so, and the lib half is what differs.

For musl, bin/sysroot builds musl 1.2.5 for x86_64, aarch64, riscv64 and armv7 hard float, and the release sysroots-2026-09-23 has the four archives, each about 2 MiB and installing to between 7 and 13 MB. They hold musl’s headers and its static libraries and start files, and not the Linux uapi headers, which are KERNEL_HEADERS and fetched once for every Linux target. Both runs that produced them, on two machines, packed the same bytes.

For glibc, bin/glibc-sysroot puts together the merged header tree of every pinned release from 2.28 to 2.44 with glibc 2.44’s start files and libc_nonshared.a, for x86_64, i686, aarch64, armv7 hard float, riscv64, powerpc64le, s390x and loongarch64, and the release sysroots-2026-09-24b has the eight archives, each under 600 KB. The seven whose ABI has a glibc older than 2.33 also carry libc_nonshared_stat.a, the stat family those releases kept in libc_nonshared.a, which crate::link::LinkLine::glibc adds for a pin before 2.33. There is no libc.so in them, because the driver writes the stubs itself, and one archive serves every release of its target, which is pinned_for_target. server2 and server3 built them from separate inputs and packed the same bytes.

Every other target is still unpublished, which is a statement about producers rather than about this table: --fetch of one says so by name, and the day a tree for it is published is the day a row for it is added here. The rows that are here are the first thing --fetch has ever had anything to move, so they are also what the fetch and the install are tested against.

Structs

Pinned

One artifact: the sysroot for one target, as this release pins it.

Constants

KERNEL_HEADERS

The Linux uapi header tree, which every Linux target reads beside its own sysroot.

PINNED

Every artifact this release pins, in tuple order.

Functions

glibc_base

The same glibc target with its release left off, or None for a target that is not glibc or names no release.

pinned_for

The artifact this release pins for tuple, if it pins one.

pinned_for_target

The artifact this release pins for a target, which for a glibc tuple that names a release is the one for the same tuple without it.

pinned_targets

Every target this release pins an artifact for, for a message that has to say what there is.