Platforms and toolchains, in detail
The README says which platforms are gated and names the three caveats you can hit in your first hour. This page is the rest: which lanes skip on which host, why each one skips, and which C compilers have been measured against the corpus. It is written for someone porting, packaging or debugging a red gate — not for someone deciding whether to try the language.
Every skip named here prints its own reason at gate time. An unenumerated skip is a gate failure, not a quiet pass (controls).
C toolchains
gcc, or clang 15 or newer. The floor is not a guess; it is where a measured miscompile stops.
| toolchain | measured | result |
|---|---|---|
| clang 14 | Ubuntu 22.04 | not supported — builds the compiler, then miscompiles what it emits: eight fixtures come back with empty strings where a string literal was expected |
| clang 15+ | the floor this repo states | supported |
| clang 19 | whole fixture corpus, against gcc | agrees on every fixture |
| clang 22.1.8 | whole corpus | builds tychoc, bootstraps tychoc1 through both stages, corpus clean — each fixture built twice, native and under -fsanitize=address,undefined, byte-identical output required between them |
| gcc (C11) | the development default | supported |
MSVC is not a supported C target and is not planned. Native Windows means MSYS2
- mingw-w64.
macOS / Apple Silicon
make ci is green on darwin-arm64. Setup is xcode-select --install. 0.9.2 ships a darwin-arm64 archive built natively on Apple Silicon; scripts/release.sh compiles a program from the extracted tarball before publishing it.
It carries 12 skips over 7 causes, each printing its reason: gdb, -Wl,--wrap, the glibc symbol floor, ilp32, resource.prlimit, an x86-64 --target leg, and LeakSanitizer.
Apple's AddressSanitizer ships no LeakSanitizer, so the fuzz-leak lane and the raytrace and mandelbrot leak legs do not run on macOS. ASan, UBSan and TSan all do. Linux is the only host that scores leaks, which is why a leak regression must be caught there.
Mobile target gates
Android and iOS are compiler target gates, not end-user platforms. Both build the same emitted C; neither ships an app template, APK, Xcode project, JNI/asset-manager binding or signed-device run.
- Android —
make android-checkcross-compiles the dependency-free corelib tests with the NDK and runs the static bionic binaries under qemu-user. Green for 84 tests on x86_64 and aarch64 at API 34. The host emulator crashes on this Fedora kernel, so runtime evidence is qemu-user, not the emulator. - iOS —
make ios-checkruns 81 dependency-free corelib tests in the Xcode iOS Simulator and builds the same emitted C against the arm64 device SDK. There is no signed physical-device run.
Neither gate is part of make ci on Linux; run them on a host with the NDK or Xcode. They are not release archives.
Linux
x86-64 is the development host and the reference platform: the full fixture suite under ASan/UBSan/LeakSanitizer, plus every gate lane.
arm64 is gated — make test is green on Ubuntu 26.04 / aarch64, run in a VM on the Apple Silicon box at native speed. No Graviton artifact is built yet.
The comma-decimal locale (FRICTION-111)
tests/float_lit_locale and float_str_locale prove that float formatting does not move when the C locale does, which needs a locale whose decimal point is not .:
sudo locale-gen da_DK.UTF-8 # or de_DE.UTF-8 / fr_FR.UTF-8
A stock container or CI image ships only C/POSIX/en_US, so without one both fixtures fail with hostile=1 expected, got 0 — the fixture refusing to pass while proving nothing, which is the correct behaviour for a control that cannot discriminate. The cure is the line above.
Running the whole gate on Linux from a Mac
make ci-linux clones HEAD into a throwaway debian:trixie podman container, installs the packages this page lists, enables a comma-decimal locale and runs make ci there. It tests the last commit, not the working tree. Nothing hosted runs this repository's gate; this target is the Linux half of it.
Optional corelib dev libraries
The FFI-backed corelib packages need their dev libraries, or make shim-warn refuses — it compiles 9 shims, wants 10, and will not read an empty warning file as a pass:
sudo apt-get install zlib1g-dev libssl-dev libcurl4-openssl-dev \
libpng-dev libsqlite3-dev pkg-config
Windows
Two supported paths. WSL2 is the zero-setup one and behaves exactly like Linux. Native Windows is MSYS2 + mingw-w64, and make ci is green there on x86-64 Windows 11 under mingw-w64 gcc.
Read that green with its scope. It is one box, one toolchain, and it carries 49 Windows-specific skips, each printing its reason:
- the sanitizer lanes — mingw ships no ASan/UBSan runtime, and gcc has no TSan for a Windows target at all
- the fuzzer
- the 32-bit lane
- the
LD_PRELOADlocale lane - the POSIX-only emitted C
- the perf gate
- every lane that needs a POSIX signal delivered to a process —
core:signal's test and the HTTP server's six shutdown cases — because MSYS2'skillterminates a native Windows program instead of signalling it
Green there means every runnable lane passed; 49 lanes skip on this host.
One measured behavioural difference
A thread parked in recv on an accepted connection is not released by the shutdown handler as it is on Linux, so a Windows server winds down within its idle timeout rather than within a millisecond. Nothing is lost or corrupted — the wind-down is slower, and only that. This is a documented platform limit, not a bug awaiting a fix; SECURITY.md carries the measurement.
The sanitizer hole, and what closed most of it
The Windows-only code paths long had no memory-safety checking at all. Installing MSYS2's clang64 toolchain closes most of that — 60 corpus fixtures under ASan+UBSan and the 13-program concurrency suite under UBSan all come back clean — but ASan itself does not work on threaded programs with that toolchain, so the channel and allocator paths have UBSan coverage only.
That is not parity with Linux, where everything runs under ASan/UBSan/TSan and a fuzz campaign. The behavioural gaps that survive the port — non-ASCII filenames, TZ handling, core:os through cmd.exe, the debugger's Ctrl-C — are listed in SECURITY.md.
Windows arm64 is a mingw target, executed by make platform-check. A subnormal-literal defect there was a toolchain bug that lane found, and it is fixed.
Release artifacts
Release tarballs are built per platform by scripts/release.sh (--mingw cross-builds the Windows one). make release-check builds and smoke-tests the current-version tarball twice and requires byte-identical archives.
See also: SUPPORT.md for which platforms carry a *promise* · controls for why every skip is enumerated · the friction log for FRICTION-91 and FRICTION-111.