Platform Support

macOS (arm64)

The primary platform. clang — preinstalled with the Xcode Command Line Tools — is the only system dependency for producing binaries. The full surface is supported: the language, the stdlib, the Node API surface including the server stack, --dynamic, and the sanitizer lane.

Cross-compilation via zig

scriptc cross-compiles from macOS using zig's bundled clang and sysroots. Install zig, then select it with two environment variables:

SCRIPTC_CC=zigcc

Use zig's clang as the C compiler.

SCRIPTC_TARGET=<triple>

The target triple; GNU/Linux targets include a glibc version.

Linux (arm64, x86_64)

$ SCRIPTC_CC=zigcc SCRIPTC_TARGET=aarch64-linux-gnu.2.36 scriptc build fib.ts -o fib-linux
$ file fib-linux
fib-linux: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 2.0.0, with debug_info, not stripped

The runtime has native Linux backends throughout: the event loop is epoll (kqueue on macOS), the server stack and TLS (with distro CA-bundle probing) and fs.watch all have Linux implementations, verified against Linux Node in a container-based differential lane. x86_64-linux-gnu.2.36 works the same way. For Alpine containers, use x86_64-linux-musl; Zig produces a statically linked executable and the same static runtime surface is verified against Node on Alpine.

Windows (x86_64)

$ SCRIPTC_CC=zigcc SCRIPTC_TARGET=x86_64-windows-gnu scriptc build fib.ts -o fib.exe
$ file fib.exe
fib.exe: PE32+ executable (console) x86-64, for MS Windows

The full corpus runs in a differential lane against Windows Node, including --dynamic programs and child_process. The Windows fixture lanes also exercise real loopback traffic through net, http, https, tls, http2, dgram, and dns, plus the native fetch implementation (including redirects, streaming bodies, compression, cancellation, and proxy handling).

iOS and Android (arm64, library mode)

Three mobile triples build library-mode static archives for an embedding app to link — a mobile app is the executable, so scriptc build without --lib rejects these targets with SC3002:

SCRIPTC_TARGET=aarch64-apple-ios

iOS device archives (Mach-O, arm64). Requires a macOS host with Xcode's iPhoneOS SDK. Every object carries LC_BUILD_VERSION with minimum OS 15.0.

SCRIPTC_TARGET=aarch64-apple-ios-simulator

iOS simulator archives (Mach-O, arm64, simulator platform). Requires a macOS host with Xcode's iPhoneSimulator SDK. Same iOS 15.0 minimum.

SCRIPTC_TARGET=aarch64-linux-android

Android archives (ELF, arm64) compiled against the NDK's bionic headers at API level 26 — the embedder's minSdkVersion must be 26 or higher. Requires an Android NDK: ANDROID_NDK_ROOT, or the newest ndk/<version> under ANDROID_HOME or the default SDK location.

$ SCRIPTC_CC=zigcc SCRIPTC_TARGET=aarch64-apple-ios scriptc build --lib --profile app.profile.json
$ SCRIPTC_CC=zigcc SCRIPTC_TARGET=aarch64-linux-android scriptc build --lib --profile app.profile.json

The full library-mode feature set applies: profile-declared exports and ABI entry points, host-callback channels (callbacks + abi.callback_register_symbol), contract sidecars, determinism fences, abi.localize_runtime (multi-instance archives — Mach-O localization runs the macOS host linker for both iOS platforms; Android rides the same in-process ELF localization as the Linux cross targets), and abi.instance_per_thread (thread-instanced state). The archive's external-symbol contract is unchanged: undefined references only to the target's C/math runtime and system APIs, resolved by Xcode's link against the selected SDK or the NDK clang link at API 26+. Simulator and emulator execution of the archive probes is part of the test matrix; device-architecture archives are build- and link-verified.

WebAssembly (WASI Preview 1)

Set SCRIPTC_CC=zigcc and SCRIPTC_TARGET=wasm32-wasi to produce a standalone .wasm module. Without -o, scriptc build hello.ts writes .scriptc/hello.wasm. scriptc run hosts the module with Node's WASI implementation, inherits stdio and environment, preopens the current working directory as /, and maps the host platform's temporary directory to the guest's /tmp. A built module can run in another WASI Preview 1 host instead.

WASI is a production LLVM target with the same language tiers as the native targets. Its 32-bit LLVM ABI supports collections, closures, exceptions, classes, checked dynamic values, async/await, promises, synchronous and asynchronous generators, timers, stdin/readline events, process-exit listeners, filesystem callbacks and promises, and the --dynamic QuickJS island. The debugging C backend remains available for async-free inspection only through an explicit --backend c; coroutine-dependent programs report SC3001, and WASI never silently falls back to C.

The remaining executable boundary is host capability, not language coverage. WASI Preview 1 has no portable socket, process-spawn, OS-signal, network-interface, or filesystem-notification APIs. Networking/fetch, child processes, signal APIs, os.networkInterfaces(), and fs.watch therefore fail before linking with diagnostic SC3002. --sanitize, native FFI, and library-mode archive builds are unavailable too. Filesystem behavior is bounded by the host's preopens, and process/OS introspection follows WASI's reduced model.

Cross-target limits

• --sanitize is a host-build lane.
• Library-mode static archives are native embedder artifacts; wasm32-wasi rejects scriptc build --lib with SC3002.
• Mobile triples are library-mode-only: standalone executable builds reject with SC3002, and only the library-admissible surface (the async-free static tier a library archive links) is supported there.
• iOS targets build on macOS hosts only (the Apple SDK sysroot and Mach-O localization); Android targets build from any host with an NDK.
• WASI cannot host APIs for capabilities missing from Preview 1, as described above.

Summary