--- name: schos-cross-platform-build description: "The build and tools support Windows, Linux, macOS and BSD; clang everywhere, and the four host assumptions that used to break" metadata: node_type: memory type: project originSessionId: 9d8a2aef-bcf0-47a0-96c6-f706efab4a95 modified: 2026-08-09T12:26:54.787Z --- **Nexoniarz develops from both Windows and Linux and switches between them**, so nothing in the build may assume a host. As of 2026-08-09 all four are supported: Windows (Git Bash/MSYS), Linux, macOS, and the BSDs. See [[schunix-build-environment]] for why WSL is not an option on the Windows box. **One toolchain, not two.** clang is a cross-compiler by construction, so a single LLVM install produces every target the tree needs — bare-metal ELF, the 16/32-bit code below 1 MB, and Linux/musl userland — from any host. The Makefile picks clang+lld whenever both are on PATH; `USE_GNU=1` forces the GNU fallback. The old GNU branch had rotted: it passed `--no-warn-rwx-segments`, which is a **hard error on lld**, and lld is the default linker on FreeBSD and macOS. It also wanted a brewed `x86_64-elf-gcc` before a Mac could build at all. **Host tools use the host's own `cc`.** Only mingw needs naming explicitly, and only because clang defaults to an MSVC target there while `tools/mkfs.c` needs `` and ``. **The four things that were actually host-specific**, all fixed — worth recognising the pattern before adding a fifth: 1. `` is glibc/musl only. macOS and the BSDs have no such header and take `major()`/`minor()` from ``. Guarded on `__linux__` now. 2. `sha256sum -c -` exists on Linux and Git Bash only. macOS has `shasum -a 256`, FreeBSD/NetBSD `sha256`, OpenBSD `cksum -a sha256`. `tools/sha256check.sh` tries all five and compares digests itself rather than trusting a `-c` flag, whose input format also differs. 3. `nproc` is coreutils — absent on macOS and BSD, where it is `sysctl -n hw.ncpu`. 4. **`Join-Path $root 'build\x'` produces a filename containing a backslash on a Unix host.** PowerShell 7 runs on Linux/macOS/BSD, so the .ps1 tools are usable there, but only with forward slashes throughout and QEMU found on PATH instead of a hardcoded scoop location. **Do not blanket-replace backslashes in the .ps1 tools.** `bootcheck.ps1` sends `printf 'caf\303\251'` to the guest to test UTF-8; rewriting those octal escapes changes what the test asserts without failing it. The sweep is restricted to known directory prefixes for exactly this reason. **Ports do not build on Windows** — `make ports` skips with a message and the tree relies on `sysroot/` being pre-staged. Building musl/toybox/mksh from source needs a Linux host. That is a real reason to keep the Linux path working, not a theoretical one. **Unverified, and say so when it matters:** the Linux, macOS and BSD paths are written from documented behaviour and have **never been executed** — this machine has no WSL and no second host. Windows is the only host where the build and `tools/bootcheck.ps1` have actually been run green.