Files
claude@clouddev1 04ebd83f08 build: D1 cross-compile via cargo-zigbuild (4 non-macOS targets)
Replace the single-target musl cc with cargo-zigbuild + zig in the flake
devShell — one universal cross cc/linker (incl. rusqlite's bundled SQLite
C) for all four non-macOS D1 targets, added to rust-toolchain.toml:
  x86_64/aarch64-unknown-linux-musl              (static, D2)
  x86_64-pc-windows-gnu, aarch64-pc-windows-gnullvm  (standalone .exe)

Windows links -lsynchronization (std WaitOnAddress), which rust-overlay's
toolchain and zig's mingw don't ship; the symbols are forwarded by
kernel32, so an empty stub libsynchronization.a (ci/winstub/, wired via
.cargo/config.toml for the windows targets only) satisfies the linker.
Verified: all four build; linux static; windows valid PE32+.
2026-06-13 12:14:49 +00:00

1.1 KiB

ci/winstub/ — empty Windows import-lib stub

libsynchronization.a here is an empty ar archive (8 bytes: !<arch>\n), referenced by .cargo/config.toml via -L native=ci/winstub for the Windows release targets.

Why

The D1 release matrix cross-compiles Windows binaries from Linux with cargo zigbuild (see docs/ci/adr/). Rust's std links -lsynchronization for its WaitOnAddress-based thread parking. That import library is normally provided by Rust's rust-mingw "self-contained" component — which rust-overlay does not ship — and Zig's bundled mingw doesn't carry it either, so the link fails with:

error: unable to find dynamic system library 'synchronization'

The functions it would import (WaitOnAddress, WakeByAddressSingle, WakeByAddressAll) are forwarded by kernel32.dll, which is already linked, so they resolve at link and run time without a real synchronization import library. An empty stub is therefore sufficient: it satisfies the -l lookup and contributes no symbols.

Regenerating

zig ar rcs ci/winstub/libsynchronization.a