fix: Copy extra components on darwin

[domwst]

Hi! After updating to a fresh version of rust I've started getting these kinds of errors from rust-lld on macos:

dyld[57979]: Library not loaded: @rpath/libLLVM.dylib
  Referenced from: <1A2A643B-408F-3C7A-B8A2-DC5EDCCD6D11> /nix/store/dsd8a65z7w5dl4i0h8g45qkc2hmk2vva-rustc-1.98.0-nightly-2026-06-02-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/bin/rust-lld
  Reason: tried: '/nix/store/dsd8a65z7w5dl4i0h8g45qkc2hmk2vva-rustc-1.98.0-nightly-2026-06-02-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), '/System/Volumes/Preboot/Cryptexes/OS/Users/runner/work/rust/rust/build/aarch64-apple-darwin/llvm/lib/libLLVM.dylib' (no such file), '/nix/store/dsd8a65z7w5dl4i0h8g45qkc2hmk2vva-rustc-1.98.0-nightly-2026-06-02-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), '/System/Volumes/Preboot/Cryptexes/OS/Users/runner/work/rust/rust/build/aarch64-apple-darwin/llvm/lib/libLLVM.dylib' (no such file)

It looks like recent versions of helper binaries link dynamically to libLLVM.dylib. The tools live under lib/rustlib/<target>/bin and their rpath include @loader_path/../lib, so dyld expects LLVM at lib/rustlib/<target>/lib/libLLVM.dylib. However, the rustc component provides libLLVM.dylib under: lib/libLLVM.dylib, current fix symlinks the libLLVM.dylib into the corresponding relative path.

This issue was likely triggered by:
rust-lang/rust#157205

There is also
rust-lang/rust#157557
which will likely affect x86_64-darwin as well.

I've tested the fix on aarch64-darwin and x86_64-linux manually (although with llvm-tools-preview component enabled).

[oxalica]

It looks like recent versions of helper binaries link dynamically to libLLVM.dylib. The tools live under lib/rustlib/<target>/bin and their rpath include @loader_path/../lib, so dyld expects LLVM at lib/rustlib/<target>/lib/libLLVM.dylib. However, the rustc component provides libLLVM.dylib under: lib/libLLVM.dylib, current fix symlinks the libLLVM.dylib into the corresponding relative path.

I'm kinda confused. If these tools expect libLLVM at lib/rustlib/<target>/lib/libLLVM.dylib where it isn't, how does rustup make them work?

[domwst]

Great question.

As far as I understand, rustup normally places libLLVM in the lib/ folder, but it gets away with such library placement because it modifies DYLD_FALLBACK_LIBRARY_PATH environment variable to make loader look for libLLVM at that custom path (cargo and others are mere symlinks to the rustup so it can modify environment variables before exec'ing downstream binary).

There is however a second part to this story: llvm-tools-preview component ships libLLVM.dylib at lib/rustlib/<target>/lib/, which makes placement look correct (this library is placed into ../lib path relative to the binaries at lib/rustlib/<target>/bin/), but the binaries in the lib/rustlib/<target>/bin/ folder are not the actual binaries but a symlinks to some other place in the nix storage and the relative dynamic library search path is measured from that location, so having llvm-tools-preview component installed doesn't help to mitigate the issue either.

[oxalica]

... it modifies DYLD_FALLBACK_LIBRARY_PATH environment variable to make loader look for libLLVM at that custom path (cargo and others are mere symlinks to the rustup so it can modify environment variables before exec'ing downstream binary).

Okay so they did the load path trick as well...

There is however a second part to this story: llvm-tools-preview component ships libLLVM.dylib at lib/rustlib/<target>/lib/, which makes placement look correct (this library is placed into ../lib path relative to the binaries at lib/rustlib/<target>/bin/), but the binaries in the lib/rustlib/<target>/bin/ folder are not the actual binaries but a symlinks to some other place in the nix storage and the relative dynamic library search path is measured from that location, so having llvm-tools-preview component installed doesn't help to mitigate the issue either.

So does this mean if we install all components into a single derivation instead of symlinking (and make relevant components depends on llvm-tools-preview), they should work as well? That may be an option for us in the future though.

[oxalica]

Anyways, thanks for the fix!

[domwst]

So does this mean if we install all components into a single derivation instead of symlinking (and make relevant components depends on llvm-tools-preview), they should work as well? That may be an option for us in the future though.

It should work, but I didn't test it. It would also require identifying the exact set of components that have this dependency and introducing an extra dependency to bring in a library that is already bundled with other components.

Thanks for merging!