Skip to content

Install additional LLVM DLL on Windows #156229

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rust-bors merged 1 commit into from
May 22, 2026
+6 −0
Merged

Install additional LLVM DLL on Windows #156229

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions src/bootstrap/src/core/build_steps/dist.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2569,6 +2569,12 @@ pub fn maybe_install_llvm_runtime(builder: &Builder<'_>, target: TargetSelection
// statically.
if builder.llvm_link_shared() {
maybe_install_llvm(builder, target, &dst_libdir, false);

// To workaround lack of rpath on Windows, we bundle another copy of
// the LLVM DLL to make rust-lld and llvm-tools work when `sysroot/bin`
// is missing from PATH, i.e. when they not launched by rustc.

@Mark-Simulacrum Mark-Simulacrum May 14, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, what is putting these tools on PATH? Is this mostly for directly calling them in ad-hoc scripts of various kinds? I'm wondering if we should be employing wrapper binaries, similar to https://github.com/rust-lang/rust/blob/main/src/tools/lld-wrapper/src/main.rs, which setup PATH appropriately?

I guess for llvm-tools we'd need a bunch of those wrappers which doesn't seem amazing.

I think I'm OK with this overall, it's a bit annoying and I'm not convinced the issue is a 'stable' guarantee (i.e., whether this is actually a regression or just a problem in a pseudo-unstable surface area)... but the fix seems relatively minimal, so maybe it's the right thing.

@mati865 mati865 May 14, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK https://crates.io/crates/cargo-binutils is the only way to use them beside calling them manually.

I'm wondering if we should be employing wrapper binaries, similar to main/src/tools/lld-wrapper/src/main.rs, which setup PATH appropriately?

I guess for llvm-tools we'd need a bunch of those wrappers which doesn't seem amazing.

Technically that would work but given the number of binaries it doesn't seem feasible. Note that currently rust-lld binary which is called by our lld-wrappers is also affected, unless called by rustc which adds $SYSROOT/bin to the PATH.

I think I'm OK with this overall, it's a bit annoying and I'm not convinced the issue is a 'stable' guarantee (i.e., whether this is actually a regression or just a problem in a pseudo-unstable surface area)... but the fix seems relatively minimal, so maybe it's the right thing.

LLVM tools component is hard to quantify whether it's stable or not. IIRC it was accidentally stabilised and just left that way.
Given the pain DLLs are when dealing with I wish we could just make it required to use the patterns:

PATH=$SYSROOT/lib/rustlib/<target>/bin:$SYSROOT/bin <llvm tool name>

# or

PATH=$SYSROOT/bin $SYSROOT/lib/rustlib/<target>/bin/<llvm tool name>

let dst_libdir = sysroot.join("lib/rustlib").join(target).join("bin");
maybe_install_llvm(builder, target, &dst_libdir, false);
}
}

Expand Down
Loading