On aarch64-apple-darwin, rust-objcopy (shipped in the rustc component) has the same broken rpath as rust-lld in #163947, but #163954 doesn't fix it. That PR only changes the rpath flags in the Lld bootstrap step. rust-objcopy is a renamed copy of llvm-objcopy from the main LLVM build (compile.rs, "copying llvm-objcopy as rust-objcopy"), so it keeps LLVM's default @loader_path/../lib.
Since #157205 (first stable: 1.98.0), rust-objcopy links libLLVM.dylib dynamically:
$ B="$(rustc +1.98.1 --print sysroot)/lib/rustlib/aarch64-apple-darwin/bin"
$ otool -L "$B/rust-objcopy"
@rpath/libLLVM.dylib (compatibility version 1.0.0, current version 22.1.8)
/usr/lib/libc++.1.dylib (...)
/usr/lib/libSystem.B.dylib (...)
$ otool -l "$B/rust-objcopy" | grep -A2 LC_RPATH
path @loader_path/../lib (offset 12)
@loader_path/../lib resolves to lib/rustlib/aarch64-apple-darwin/lib/. The rustc component ships the dylib only at lib/libLLVM.dylib, per manifest-rustc-aarch64-apple-darwin. On 1.97.0, rust-objcopy doesn't link libLLVM at all.
Impact
rustc runs rust-objcopy to strip debuginfo (the default for release profiles on macOS). When it runs without rustup's DYLD_FALLBACK_LIBRARY_PATH shim, dyld aborts it with Library not loaded: @rpath/libLLVM.dylib (SIGABRT). rustc reports that as a warning only, so the build succeeds but the binary keeps its debuginfo. For example, one of our release binaries came out at 57 MB instead of being stripped. This is easy to miss in CI and packaging.
Workaround
Same as #163947:
ln -s ../../../libLLVM.dylib "$(rustc +1.98.1 --print sysroot)/lib/rustlib/aarch64-apple-darwin/lib/libLLVM.dylib"
Suggested fix
Add @loader_path/../../../ to the rpath of the LLVM tools copied into lib/rustlib/<host>/bin, the same way #163954 does for LLD. That could go in the LLVM cmake step's ldflags, or come from an install_name_tool -add_rpath when rust-objcopy is copied. I haven't checked whether Linux rust-objcopy has a matching $ORIGIN/../../../ entry.
Meta
rustc 1.98.1 (48a229cea 2026-09-01)
host: aarch64-apple-darwin
LLVM version: 22.1.8
I've only tested 1.98.1. I expect 1.99.0 to behave the same, because #163954 doesn't touch this path.
Disclosure: diagnosis and draft were produced with an LLM (Claude) and checked by me against the toolchain on my machine.
On
aarch64-apple-darwin,rust-objcopy(shipped in therustccomponent) has the same broken rpath asrust-lldin #163947, but #163954 doesn't fix it. That PR only changes the rpath flags in theLldbootstrap step.rust-objcopyis a renamed copy ofllvm-objcopyfrom the main LLVM build (compile.rs, "copyingllvm-objcopyasrust-objcopy"), so it keeps LLVM's default@loader_path/../lib.Since #157205 (first stable: 1.98.0),
rust-objcopylinkslibLLVM.dylibdynamically:@loader_path/../libresolves tolib/rustlib/aarch64-apple-darwin/lib/. Therustccomponent ships the dylib only atlib/libLLVM.dylib, permanifest-rustc-aarch64-apple-darwin. On 1.97.0,rust-objcopydoesn't linklibLLVMat all.Impact
rustc runs
rust-objcopyto strip debuginfo (the default for release profiles on macOS). When it runs without rustup'sDYLD_FALLBACK_LIBRARY_PATHshim, dyld aborts it withLibrary not loaded: @rpath/libLLVM.dylib(SIGABRT). rustc reports that as a warning only, so the build succeeds but the binary keeps its debuginfo. For example, one of our release binaries came out at 57 MB instead of being stripped. This is easy to miss in CI and packaging.Workaround
Same as #163947:
ln -s ../../../libLLVM.dylib "$(rustc +1.98.1 --print sysroot)/lib/rustlib/aarch64-apple-darwin/lib/libLLVM.dylib"Suggested fix
Add
@loader_path/../../../to the rpath of the LLVM tools copied intolib/rustlib/<host>/bin, the same way #163954 does for LLD. That could go in the LLVM cmake step's ldflags, or come from aninstall_name_tool -add_rpathwhenrust-objcopyis copied. I haven't checked whether Linuxrust-objcopyhas a matching$ORIGIN/../../../entry.Meta
I've only tested 1.98.1. I expect 1.99.0 to behave the same, because #163954 doesn't touch this path.
Disclosure: diagnosis and draft were produced with an LLM (Claude) and checked by me against the toolchain on my machine.