Platform Support

By default, scriptc build produces an executable for the machine you are building on. To build for another operating system, another architecture, or WebAssembly, set SCRIPTC_TARGET to the target you want. This page lists the supported platforms and shows how to cross-compile for each one.

Supported platforms

The compiler runs on:

• macOS 15 or later on arm64 and x64.
• Linux on arm64 and x64, with glibc 2.34 or later or with musl.
• Windows on x64.

It can build:

• Executables for macOS (arm64, x64; macOS 14.0 minimum), Linux (arm64, x64; glibc or musl), and Windows (x64).
• WebAssembly modules for WASI Preview 1.
• Static libraries for iOS and Android apps, in library mode.

Building an executable needs a linker and the platform's SDK or system libraries: clang from the Xcode Command Line Tools on macOS, clang on glibc-based Linux, and zig on Windows, on musl-based Linux, and for WASI, Android, and cross-compiled targets. Set SCRIPTC_LINKER to use a different linker driver. Assembly and object output (--emit=asm or --emit=obj) need no external tools.

Cross-compile

The installed compiler can build for its own platform out of the box. To build for another target:

1. Install zig, which scriptc uses to link executables for other targets.
2. Add the target's runtime pack to your project, at the same version as scriptc --version. Runtime packs are named @scriptc/runtime-<target>, for example @scriptc/runtime-linux-arm64-gnu or @scriptc/runtime-wasm32-wasi.
3. Run scriptc build from your project with SCRIPTC_TARGET set to the target triple.

$ npm install --save-dev @scriptc/runtime-linux-arm64-gnu@0.3.0
$ SCRIPTC_TARGET=aarch64-linux-gnu.2.36 scriptc build fib.ts -o fib-linux >/dev/null

You can also point SCRIPTC_RUNTIME_PACK at a runtime pack directory, which is useful with the standalone compiler archives. Adding a pack doesn't require reinstalling the compiler.

Linux (arm64, x86_64)

GNU/Linux triples can name the minimum glibc version, 2.34 (the default) or 2.36:

$ 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

x86_64-linux-gnu.2.36 works the same way. For Alpine and other musl-based systems, use aarch64-linux-musl or x86_64-linux-musl; these produce statically linked executables.

Linux executables use the native Linux implementations of the event loop (epoll), servers, TLS (with the system's CA bundle), and fs.watch, and they are tested against Node.js on Linux, including Alpine.

Windows (x86_64)

$ 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

Windows executables support child_process, net, http, https, tls, http2, dgram, dns, and fetch, and they are tested against Node.js on Windows.

Executables open a console window by default. For an application that shows its own window, build with --windows-subsystem=gui so Windows doesn't open an extra console.

WebAssembly (WASI)

WASI is a cross-compile target, so it needs zig and the @scriptc/runtime-wasm32-wasi runtime pack, as described in Cross-compile. Install the runtime pack in your project at the same version as scriptc --version. Without it, the build fails with SC3003.

Set SCRIPTC_TARGET=wasm32-wasi to build a standalone .wasm module:

$ npm install --save-dev @scriptc/runtime-wasm32-wasi@0.3.5
$ SCRIPTC_TARGET=wasm32-wasi scriptc build hello.ts >/dev/null
$ SCRIPTC_TARGET=wasm32-wasi scriptc run hello.ts
hello, world

Without -o, the module is written to .scriptc/hello.wasm. scriptc run runs it with Node.js's WASI implementation, so it needs Node.js 24 or later on your PATH. It passes through stdio and environment variables, makes the current directory available as /, and maps the host's temporary directory to /tmp. You can run a built module in any other WASI Preview 1 runtime too.

WASI modules support the same language features as native executables, including async functions, promises, generators, timers, stdin and readline, and filesystem callbacks and promises. WASI Preview 1 has no sockets, process spawning, signals, network interfaces, or file watching, so networking and fetch, child processes, signal APIs, os.networkInterfaces(), the os host facts without a WASI equivalent (cpus(), hostname(), freemem(), loadavg(), uptime(), getPriority()), and fs.watch fail the build with SC3002. --sanitize and native FFI aren't available for WASI.

To build a module that a web or native application calls into, see WebAssembly Modules.

iOS and Android (arm64)

On mobile, the app is the executable, so scriptc builds a static library that the app links. Use library mode with one of these targets:

SCRIPTC_TARGET=aarch64-apple-ios

iOS devices. Requires a macOS host. Minimum iOS 15.0.

SCRIPTC_TARGET=aarch64-apple-ios-simulator

The iOS simulator on Apple silicon. Requires a macOS host. Minimum iOS 15.0.

SCRIPTC_TARGET=aarch64-linux-android

Android devices, built against API level 26; the app's minSdkVersion must be 26 or higher. Builds from any supported host with zig.

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

The library profile declares the exported functions, the host callbacks the library can call, and options such as running several independent instances in one app (abi.localize_runtime) or one instance per thread (abi.instance_per_thread). Xcode or the Android NDK performs the final link against the platform SDK. Building these targets without --lib fails with SC3002, and library builds don't support async functions, promises, or timers.

Cross-target limits

• --sanitize is available only when building for the host platform.
• Native FFI inputs (objects and archives) must already be built for the target; scriptc doesn't translate them.
• iOS targets build only on macOS hosts.
• WASI builds can't use APIs that need capabilities WASI Preview 1 lacks, as described above.

Summary