Use LLVM 20 throughout the Linux build - #741
Merged
Merged
Conversation
The build installs clang-20 and llvm-20, then puts /usr/lib/llvm-18/bin on PATH. Nothing installs llvm-18, so that directory does not exist and the entry does nothing. It has been harmless so far because the two tools the build cares about are passed by absolute path, /p:ClangToolExe=/usr/bin/clang-20 and /p:LlvmArToolExe=/usr/bin/llvm-ar-20. Anything resolved by name off PATH would miss the LLVM 20 binaries entirely and fall back to whatever the image happens to provide. develop already reads llvm-20 here, so this looks like a version bump that updated the install line and missed the one below it.
The first commit on this branch called the llvm-18 entry on PATH dead, because nothing installs llvm-18. CI disagreed, and the build failed with error : unable to execute command: Executable "lld-link" doesn't exist! error : invalid linker name in argument '-fuse-ld=lld' which is the same failure that was blocking #716 back at the start of all this. The runner image ships LLVM 18 of its own, and that directory was supplying lld. The entry was not dead, it was the only thing providing a linker. The apt llvm-20 package does not include lld; that lives in a separate lld-20. So installing it makes LLVM 20 self sufficient and lets the PATH entry point at the version the build actually uses. Afterwards every toolchain reference in the workflow is on 20: clang-20, llvm-20 and lld-20 installed, /usr/lib/llvm-20/bin on PATH, and ClangToolExe and LlvmArToolExe already pointing at the 20 binaries. Nothing now depends on whichever LLVM the runner image happens to carry, which is what made this fragile in the first place.
wasabii
changed the title
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.
Makes the Linux build use LLVM 20 throughout, instead of depending on whichever LLVM the runner image happens to ship.
What was there
Install 20, then put 18 on
PATH.What I got wrong first
My initial reading was that the llvm-18 entry was dead, since nothing installs llvm-18. CI disagreed immediately — changing it to llvm-20 broke the build with:
which is the same failure that was blocking #716 at the start of this work.
The runner image ships its own LLVM 18, and
/usr/lib/llvm-18/binwas supplyinglld. The entry was not dead — it was the only thing providing a linker. The aptllvm-20package does not include lld; that lives in a separatelld-20.What this does
Every toolchain reference in the workflow is now on 20:
clang-20,llvm-20,lld-20PATH/usr/lib/llvm-20/binClangToolExe/usr/bin/clang-20(already)LlvmArToolExe/usr/bin/llvm-ar-20(already)-fuse-ld=lldcomes fromIKVM.Clang.Sdkrather than this repo, so it resolves lld offPATH— which is why the version there matters.Why it is worth doing
The build was silently linking with LLVM 18's lld while compiling with clang 20. It worked, but only because the image happened to carry a matching-enough LLVM. That is what made the original
lld-linkfailure so hard to place: the dependency was on the image, not on anything the workflow declared.