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 $?
1Under 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.
On Windows, linking any program fails with
undefined symbol: clock_gettimeandundefined 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-latestGitHub Actions runner, llvm-mingw 20240619 (clang -dumpmachine→x86_64-w64-windows-gnu), Node 24.Reproduce
Under Node the same program prints
hiand exits 0.Why it happens
clock_gettimeandnanosleepare POSIX; on mingw-w64 they live inlibwinpthread, 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 inpackages/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
clangon Windows cannot compile the runtime at all, because it usesssize_talong with the two functions above, none of which the MSVC CRT provides. An llvm-mingw / MSYS2clang64/ 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
pthreadtosystem_librariesin the FFI manifest, which dragslibwinpthreadinto the link. That works, but it only helps programs that already use--ffi; a plainscriptc buildon Windows has no way to express it.