rust-lld on aarch64-apple-darwin cannot load libLLVM.dylib when the toolchain rustc is invoked directly (1.99.0, regression from 1.96.1)

On aarch64-apple-darwin, rust-lld from the 1.99.0 stable toolchain aborts at load time when the toolchain's rustc is run directly rather than through the rustup proxy, so linking a wasm32-unknown-unknown cdylib fails. Through the proxy (rustc +1.99) it links, presumably because rustup adds the toolchain's lib/ to the dylib search path. The same direct invocation works on 1.96.1 (macOS) and on 1.99.0 (aarch64 Linux). Tools that ship or pin a sysroot and invoke <sysroot>/bin/rustc by path hit this.

Reproduction

rustup toolchain install 1.99 --profile minimal --target wasm32-unknown-unknown
echo '#[unsafe(no_mangle)] pub extern "C" fn f() -> i32 { 1 }' > lib.rs
"$(rustc +1.99 --print sysroot)/bin/rustc" --crate-type=cdylib --target=wasm32-unknown-unknown lib.rs

Output

error: linking with `rust-lld` failed: signal: 6 (SIGABRT)
  = note: dyld[5821]: Library not loaded: @rpath/libLLVM.dylib
            Referenced from: ~/.rustup/toolchains/1.99-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/bin/rust-lld
            Reason: tried: '~/.rustup/toolchains/1.99-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/bin/../lib/libLLVM.dylib' (no such file), '/Users/runner/work/rust/rust/build/aarch64-apple-darwin/llvm/lib/libLLVM.dylib' (no such file), ...

Cause

Since #157205 (link LLVM dynamically on aarch64-apple-darwin), rust-lld loads @rpath/libLLVM.dylib:

$ otool -L .../lib/rustlib/aarch64-apple-darwin/bin/rust-lld
	@rpath/libLLVM.dylib (compatibility version 1.0.0, current version 23.1.1)
$ otool -l .../lib/rustlib/aarch64-apple-darwin/bin/rust-lld | grep -A2 LC_RPATH
         path @loader_path/../lib
         path /Users/runner/work/rust/rust/build/aarch64-apple-darwin/llvm/lib

@loader_path/../lib resolves to lib/rustlib/aarch64-apple-darwin/lib/, but the toolchain ships the dylib at the top-level lib/libLLVM.dylib. On Linux the equivalent rpath is $ORIGIN/../../../, which finds lib/libLLVM.so.*. On 1.96.1, macOS rust-lld had no libLLVM dependency at all.

Workaround

ln -s ../../../libLLVM.dylib "$(rustc +1.99 --print sysroot)/lib/rustlib/aarch64-apple-darwin/lib/libLLVM.dylib"

Meta

rustc +1.99 --version --verbose:

rustc 1.99.0 (b940084d7 2026-09-28)
host: aarch64-apple-darwin

@rustbot

@rustbot transfer rust-lang/rustup

@maxdexh

@maxdexh Sorry, but why transferring this issue to rustup? If this is an issue with the artifacts being generated (say the linking has a problem), rather than their means of distribution, then this is a r-l/r CD problem and I believe there is nothing we can do in r-l/rustup the repo 🤔

That said I'd love to follow the diagnosis over there.

@rustbot

I've found a related issue (nix-community/fenix#253) and it seems that rustup happens to have covered up the defect, rather than rustup having the defect itself:

rust-lang/rust#157205 (merged 2026-06-01, first stable release 1.98.0) enables llvm.link-shared=true for dist-aarch64-apple. rust-lld/rust-objcopy now link @rpath/libLLVM.dylib with rpath @loader_path/../lib, i.e. they expect lib/rustlib/<host>/lib/libLLVM.dylib. The rustc tarball only ships lib/libLLVM.dylib; the rustlib/<host>/lib copy is only produced by the llvm-tools dist step (maybe_install_llvm_target in src/bootstrap/src/core/build_steps/dist.rs).

rustup users don't see this because rustup's proxies prepend <toolchain>/lib to DYLD_FALLBACK_LIBRARY_PATH for every invoked tool (Toolchain::set_ldpath). fenix runs upstream install.sh and provides no such shim, and the rust-mixed symlink layout doesn't help since @loader_path resolves to the real path inside the rustc store path.

Given that, I still think r-l/r is the right place to hold this issue.

@rustbot transfer rust-lang/rust

Since the scope of my work includes toolchain distribution in general rather than just rustup, I'd love to dive further into this issue here.

yeah i misread the issue as saying it only works when calling the compiler directly, which would have made this an obvious rustup issue. The way it is, idk where the issue is

@rustbot

I looked more into it. On Linux we have this tweak specifically for libLLVM I believe:

rust/src/bootstrap/src/core/build_steps/llvm.rs

Lines 1724 to 1736 in 8d1a764

    
           if builder.config.rpath_enabled(target) 
        
               && helpers::use_host_linker(target) 
        
               && llvm_output.link_shared() 
        
               && target.contains("linux") 
        
           { 
        
               // So we inform LLD where it can find LLVM's libraries by adding an rpath entry to the 
        
               // expected parent `lib` directory. 
        
               // 
        
               // Be careful when changing this path, we need to ensure it's quoted or escaped: 
        
               // `$ORIGIN` would otherwise be expanded when the `LdFlags` are passed verbatim to 
        
               // cmake. 
        
               ldflags.push_all("-Wl,-rpath,'$ORIGIN/../../../'"); 
        
           }

... but somehow #157205 didn't mirror it.

I am new to this part of bootstrap, but I'd like to attempt a fix by mirroring that on darwin.

@rustbot claim

Assigning P-critical (discussion on Zulip).

@sgasho

cc @sgasho since author of #157205

Thanks for the ping, and sorry for missing this in #157205.

When I enabled llvm.link-shared for dist-aarch64-apple, I didn't realize that the Linux-only rpath tweak in Lld::run also needed to be mirrored for darwin, so it was simply left out.

The fix in #163954 looks correct to me, thanks!

Rollup merge of rust-lang#163954 - rami3l:fix/bootstrap-darwin-lld, r…

Unrolled build for #163954 in rollup 164052

Auto merge of #164232 - cuviper:stable-next, r=cuviper

Navigation Menu

Repository navigation

rust-lld on aarch64-apple-darwin cannot load libLLVM.dylib when the toolchain rustc is invoked directly (1.99.0, regression from 1.96.1) #163947

Reproduction

Output

Cause

Workaround

Meta

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	if builder.config.rpath_enabled(target)
	&& helpers::use_host_linker(target)
	&& llvm_output.link_shared()
	&& target.contains("linux")
	{
	// So we inform LLD where it can find LLVM's libraries by adding an rpath entry to the
	// expected parent `lib` directory.
	//
	// Be careful when changing this path, we need to ensure it's quoted or escaped:
	// `$ORIGIN` would otherwise be expanded when the `LdFlags` are passed verbatim to
	// cmake.
	ldflags.push_all("-Wl,-rpath,'$ORIGIN/../../../'");
	}

rust-lld on aarch64-apple-darwin cannot load libLLVM.dylib when the toolchain rustc is invoked directly (1.99.0, regression from 1.96.1) #163947

Description

Reproduction

Output

Cause

Workaround

Meta

Activity

maxdexh commented on Oct 7, 2026

rami3l commented on Oct 7, 2026

rami3l commented on Oct 7, 2026

rami3l commented on Oct 7, 2026

maxdexh commented on Oct 7, 2026

rami3l commented on Oct 7, 2026

3 remaining items

rustbot commented on Oct 8, 2026

apiraino commented on Oct 8, 2026

sgasho commented on Oct 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions