fix(ci): satisfy the phantom xml2s.lib the LLVM Windows tarball demands - #7418
Conversation
LLVM's official Windows release script builds a static libxml2 into a scratch directory and points cmake at it with -DLLVM_ENABLE_LIBXML2=FORCE_ON -DLIBXML2_LIBRARIES=%libxmldir%/lib/libxml2s.lib. %libxmldir% is never installed, so the published clang+llvm-*-pc-windows-msvc tarball carries the dependency but not the library. llvm-config --system-libs --link-static reports xml2s.lib, llvm-sys forwards every system lib verbatim with no knob to filter one out, and link.exe dies with LNK1181 before resolving a symbol. Synthesize an empty archive at the LLVM libdir when llvm-config reports xml2s.lib AND the libdir lacks it. It is a name dependency, not a symbol dependency: libxml2 is reachable only from LLVMWindowsManifest, which the LLVM-C surface inkwell drives never touches, and rustc bundles the component archives into libllvm_sys.rlib where link.exe pulls members lazily. If that stops being true the link fails loudly with LNK2019 rather than silently dropping manifest support. Checking both conditions makes the workaround self-deleting once a release ships or stops reporting the library. Latent since #7353 made the in-process LLVM backend the default and statically linked, not caused by #7388 (which touches only the Linux arm). It became visible when #7393's concurrency group let gc-native-roots.yml's windows-latest arm reach a runner for the first time. Fixing it in the composite action also unblocks test.yml's windows-build. Claude-Session: https://claude.ai/code/session_019EHcmXKArA7m42SihYCcgH
|
Warning Review limit reached
Next review available in: 46 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Windows CI cannot link
llvm-sysat all.native-roots-rs4gc (windows-latest)dies at the build step, andtest.yml'swindows-buildfails identically — so this unblocks Windows CI generally, not just one arm.Root cause: a phantom dependency baked into LLVM's own release
LLVM's
build_llvm_release.batbuilds a static libxml2 into a scratch directory and points CMake at it:%libxmldir%is never installed, so the publishedclang+llvm-*-pc-windows-msvctarball carries the dependency but not the library.llvm-config --system-libs --link-staticreportsxml2s.lib; llvm-sys forwards every system lib verbatim tocargo:rustc-link-lib; link.exe fails before resolving a single symbol.The failing link line contains
"ntdll.lib" "xml2s.lib"in exactly the--system-libsposition with/LIBPATH:C:\llvm\libpresent — the file is genuinely absent and the linker searched for it.llvm-sys has no filtering knob. Its only env vars are
LLVM_SYS_221_{PREFIX,IGNORE_BLOCKLIST,STRICT_VERSIONING,NO_CLEAN_CFLAGS,USE_DEBUG_MSVCRT,FFI_WORKAROUND}— refuting the "there's usually a way to skip optional system libs" assumption I started from.Not caused by the recent LLVM work
#7388 touched only the Linux arm (zero Windows-related lines). The Windows arm is unchanged since #7353, which made the in-process backend default and statically linked — before that, nothing on Windows linked llvm-sys. Latent since then, and invisible because three of four arms in that matrix never executed until #7393.
The fix
Windows arm only: when
llvm-configreportsxml2s.liband the libdir lacks it, synthesize an empty archive there (clang-cl /con a one-symbol stub, thenllvm-lib /OUT:), with hard failure checks on both tools and both outputs.Both conditions are deliberate so the block self-deletes: if a future release ships libxml2 or stops reporting it, this becomes a no-op rather than fabricating over the real library.
Confidence, stated honestly
Diagnosis: high — the link line, the upstream script, and the llvm-sys source agree.
Fix: moderate. I cannot test Windows locally. Two unverified assumptions, both with loud falsifiers:
LLVMWindowsManifest(lld-link, llvm-mt); the LLVM-C surface inkwell drives never touches it. Falsifier:LNK2019unresolved externals onxml*symbols. It cannot quietly mask a real dependency.clang-cl.exeandllvm-lib.exeship in the tarball — both are standard install targets, and the tarball is a full install (proven byllvm-config.exebeing present). Falsifier: the explicit "missing from the LLVM tarball" error added here.Rejected alternative:
vcpkg install libxml2:x64-windows-static— sound, but builds libxml2 and deps from source on every Windows job across 18 workflows.