Skip to content

Fix regenerate-native builds against the official LLVM release#790

Merged
tannergooding merged 1 commit into
dotnet:mainfrom
tannergooding:regenerate-native-fix-vs-generator
Jul 15, 2026
Merged

Fix regenerate-native builds against the official LLVM release#790
tannergooding merged 1 commit into
dotnet:mainfrom
tannergooding:regenerate-native-fix-vs-generator

Conversation

@tannergooding

@tannergooding tannergooding commented Jul 15, 2026

Copy link
Copy Markdown
Member

The regenerate-native workflow consumes the official LLVM release binaries, which are built with zstd and the DIA SDK enabled -- unlike ClangSharp's historical from-source LLVM build (-DLLVM_ENABLE_ZSTD=OFF, see README). The first real run of the workflow (on the LLVM 22 bump merge, #785) surfaced platform build failures; this fixes all of them.


win-x64 -- windows-latest dropped Visual Studio 2022, so the hardcoded -G "Visual Studio 17 2022" found no VS instance, and the release's baked absolute VS2022 DIA SDK diaguids.lib path caused LNK1181.

  • Drop the explicit generator so cmake auto-selects the installed Visual Studio (keeping -A/-Thost, which work with any VS generator).
  • Repoint LLVMDebugInfoPDB's baked diaguids.lib at the DIA SDK of the VS actually in use (CMAKE_GENERATOR_INSTANCE), arch-aware, and only when that replacement exists so the currently-green win-arm64 leg (still on VS2022) is unaffected.

linux-x64 / linux-arm64 -- the distro's static libzstd.a is not PIC (ld: ... recompile with -fPIC). Repoint the imported zstd::libzstd_static target at the shared libzstd.so (which is PIC).

osx-arm64 -- the official LLVM macOS release ships LTO bitcode in its static archives; Apple's system linker loads Xcode's older libLTO (v21) and fails to parse LLVM 22 bitcode (could not parse bitcode object file ... Unknown attribute kind). Point the linker at the libLTO.dylib from the LLVM release being consumed. (The Linux release archives are native objects, so this is Apple-only.)


Validated: the win-x64, linux-x64, linux-arm64, and win-arm64 legs are green on the post-merge run of the first commit; win-x64 also builds+links locally. regenerate-native runs on push: main / workflow_dispatch (not on PRs), so the macOS fix is validated by the next post-merge run.

Note

This PR body and the code changes were drafted by Copilot.

The regenerate-native workflow consumes the official LLVM release binaries,
which are built with zstd and the DIA SDK enabled -- unlike ClangSharp's
historical from-source LLVM build (-DLLVM_ENABLE_ZSTD=OFF). Consuming them
surfaced three build failures on the first real run:

* windows-latest dropped Visual Studio 2022, so the hardcoded
  -G "Visual Studio 17 2022" generator found no instance. Drop the explicit
  generator so cmake auto-selects the installed Visual Studio (keeping -A and
  -Thost, which work with any VS generator).
* The release bakes an absolute path to its build machine's Visual Studio DIA
  SDK diaguids.lib into LLVMDebugInfoPDB, causing LNK1181 on a runner with a
  different VS. Repoint it at the DIA SDK of the Visual Studio actually in use,
  only when that replacement exists so the working win-arm64 leg is unaffected.
* The distro's static libzstd.a is not PIC and cannot be linked into the shared
  library. Repoint the imported zstd target at the shared libzstd instead.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@tannergooding
tannergooding merged commit da7e208 into dotnet:main Jul 15, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant