Rollup merge of #112247 - lqd:lld-rpath, r=Mark-Simulacrum

rust-lld: add rpath entry to the correct `lib` folder

An explanation, for our linux rustup toolchain:
- `lld` / `rust-lld` is built as a regular LLVM tool, but is not distributed via the `llvm-tools` component. It's distributed by default, like a regular rust binary, like cargo and rustc. The general expected setup is: binaries in `bin` and libraries in `lib`, so the rpath we use for a `bin/$executable` is `$ORIGIN/../lib`.
- However, `rust-lld` is _not_ in the same location as our other executables (`$root/bin`), it's in `$root/lib/rustlib/$host/bin/`. The current rpath thus expects the LLVM's shared library to be in `$root/lib/rustlib/$host/lib/`.
- That .so is only present in `$root/lib`, causing #80703. (LLVM's shared library is also copied to `$root/lib/rustlib/$host/lib/` with the `llvm-tools` component, so it also was [a workaround for the issue](https://github.com/rust-lang/rust/issues/80703#issuecomment-1574788504))

rustup's `LD_LIBRARY_PATH` overrides made this discrepancy invisible when we switched to `llvm.link-shared = true`, and this only showed up when running `rustc` or `rust-lld`'s executables directly.

To fix this we could:
- copy the .so to this expected location all the time, but that seems wasteful.
- or, add an rpath entry when building LLD, which seems preferable to me (but I don't know if it could cause issues).

This PR does the latter, tweaking how bootstrap builds LLD to point to the expected directory, and fixes #80703.

(Since this is related to P-high issues about switching to lld by default, I'll cc `@petrochenkov` to keep them updated.)

0 files changed, 0 insertions, 0 deletions