ci(release-rust): use clang/lld 21 from apt.llvm.org for xwin cross-build - #99
Merged
Conversation
…uild
Ubuntu's default clang-18 mis-compiles two bundled C deps when
cross-targeting *-pc-windows-msvc via cargo-xwin:
- x86_64: zstd-sys's SSE2 intrinsics (_mm_loadu_si128, _mm_cmpeq_epi8,
_mm_movemask_epi8, ...) are left as undefined symbols -> lld-link fails.
- aarch64: the MSVC <intrin.h> is rejected with 'conflicting types for
__prefetch' (included by zstd-sys and libsqlite3-sys/rusqlite bundled).
Both Windows release targets have never linked because of this; the
release job only runs on tag pushes so PR CI never exercised it.
Verified locally with a faithful cargo-xwin + xwin-SDK + ring-shim replica:
clang-22 builds BOTH targets to working PE32+ binaries, clang-18 fails both.
Pull a modern clang/lld from apt.llvm.org and repoint the unversioned tool
names cargo-xwin + the ring .S shim resolve via PATH.
emmanuelm41
added a commit
to kunobi-ninja/kache
that referenced
this pull request
Jun 10, 2026
Cuts rc.3 to re-run the release pipeline against the fixed Windows-msvc cross toolchain (Zondax/_workflows#99 — clang/lld 21 from apt.llvm.org). rc.2's Windows builds never linked under the stale distro clang-18.
emmanuelm41
added a commit
that referenced
this pull request
Jun 10, 2026
…#100) The xwin cross job's build scripts and proc-macros link with `cc` (gcc) on the Linux runner, separate from the Windows cross compiler. The distro `clang` install previously pulled gcc in transitively; sourcing clang from apt.llvm.org (#99) no longer does, and the self-hosted runner ships no gcc, so host build scripts failed with `linker 'cc' not found` (proc-macro2, quote). Install build-essential explicitly alongside the cross toolchain.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
-pc-windows-msvcrelease targets built via cargo-xwin have never linked — thereleasejob only runs on tag pushes, so PR CI never exercised them. Both fail in bundled C deps because Ubuntu's default clang-18 mis-compiles them when cross-targeting Windows-msvc:_mm_loadu_si128,_mm_cmpeq_epi8,_mm_movemask_epi8, …) are left as undefined symbols →lld-link: undefined symbol.<intrin.h>is rejected withconflicting types for '__prefetch'(pulled in by zstd-sys and libsqlite3-sys / rusqlitebundled).Fix
Install clang/lld 21 from apt.llvm.org instead of the distro's clang-18, and repoint the unversioned tool names that cargo-xwin and the ring
.Sshim resolve via PATH.Verification
Reproduced locally with a faithful cargo-xwin + xwin-SDK + ring-
.S-shim replica of CI, varying only the clang version:_mm_*at link__prefetchconflicting typesScoped to the
if: matrix.use_xwinstep — only affects Windows-msvc cross-builds.