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+.
This commit is contained in:
claude@clouddev1
2026-06-13 12:14:49 +00:00
parent 18d08642d7
commit 04ebd83f08
5 changed files with 71 additions and 23 deletions
+17
View File
@@ -0,0 +1,17 @@
# Windows cross-link fix for the D1 release matrix (cargo-zigbuild).
#
# Rust's std links `-lsynchronization` on Windows (WaitOnAddress-based thread
# parking). Rust normally satisfies this from the `self-contained` mingw libs
# of its `rust-mingw` component — which rust-overlay does NOT ship — and Zig's
# bundled mingw (used by `cargo zigbuild`) doesn't provide `libsynchronization.a`
# either. The actual symbols are *forwarded by kernel32* (already linked), so an
# empty stub import lib is enough to satisfy the linker. See `ci/winstub/`.
#
# These sections apply ONLY when building for the Windows targets, so host
# builds (the gate's `cargo test`/`clippy`) and the Linux release targets are
# unaffected.
[target.x86_64-pc-windows-gnu]
rustflags = ["-L", "native=ci/winstub"]
[target.aarch64-pc-windows-gnullvm]
rustflags = ["-L", "native=ci/winstub"]