Windows: link fails with undefined symbol: clock_gettime / nanosleep (winpthread never linked)

On Windows, linking any program fails with undefined symbol: clock_gettime and undefined symbol: nanosleep. The runtime calls both, but the win32 link line never adds the mingw library that provides them (libwinpthread). No FFI is involved — console.log("hi") is enough.

Version: scriptc 0.0.35. windows-latest GitHub Actions runner, llvm-mingw 20240619 (clang -dumpmachine → x86_64-w64-windows-gnu), Node 24.

Reproduce

$ printf 'console.log("hi");\n' > hello.ts
$ scriptc build hello.ts -o hello.exe
ld.lld: error: undefined symbol: clock_gettime
ld.lld: error: undefined symbol: nanosleep
$ echo $?
1

Under Node the same program prints hi and exits 0.

Why it happens

clock_gettime and nanosleep are POSIX; on mingw-w64 they live in libwinpthread, not in the UCRT. The runtime references them from several translation units (scr_async.c, scr_events.c, scr_lib.c, scr_child.c, scr_bytes_io.c), but the win32 branch of the link line in packages/compiler's cc backend passes only -ladvapi32 -lbcrypt -lcrypt32 -liphlpapi -lm -lws2_32 -lz — nothing that defines them.

Adding -lwinpthread (or -lpthread, which mingw maps to it) to the win32 link libraries fixes it.

Note on toolchain choice

Related, and possibly worth a docs line: a stock MSVC-targeting clang on Windows cannot compile the runtime at all, because it uses ssize_t along with the two functions above, none of which the MSVC CRT provides. An llvm-mingw / MSYS2 clang64 / WinLibs clang works. The README lists Windows as a target but doesn't say the toolchain must be mingw-flavoured — that cost us a while to work out.

Context / workaround

We're building janela, a small Tauri-style desktop framework: the app's backend is TypeScript compiled by scriptc, and the window is the OS webview driven through a C shim, so binaries carry no JS engine of their own. Windows was the last platform to come up.

Our workaround is to add pthread to system_libraries in the FFI manifest, which drags libwinpthread into the link. That works, but it only helps programs that already use --ffi; a plain scriptc build on Windows has no way to express it.

Start in the win32 link-library branch of the cc backend under packages/compiler and inspect how system libraries are assembled. Reproduce the hello.ts build with llvm-mingw on Windows, then verify that a plain scriptc build links successfully and the resulting program prints hi and exits 0.