-
Notifications
You must be signed in to change notification settings - Fork 13.7k
rust-lld: add rpath entry to the correct lib
folder
#112247
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
rust-lld is not located in the same directory as the other binaries that point to ../lib, but in a deeper directory in lib. So we need to point a few layers up for rust-lld to find the LLVM shared library without rustup's LD_LIBRARY_PATH overrides.
@bors try |
⌛ Trying commit 17d321c with merge 6d05280785ea61c31f635fbfb61e8f988212a58b... |
☀️ Try build successful - checks-actions |
The issue is fixed on my local builds, and linking the wasm example works fine, but I was hoping we could get a On the $ readelf -d ~/.rustup/toolchains/1e17cef9e29961636db63730784caea4b7d47ff5/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld | grep PATH
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/checkout/obj/build/x86_64-unknown-linux-gnu/llvm/lib]
$ ldd ~/.rustup/toolchains/1e17cef9e29961636db63730784caea4b7d47ff5/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld | grep LLVM
libLLVM-16-rust-1.72.0-nightly.so => not found
$ ~/.rustup/toolchains/1e17cef9e29961636db63730784caea4b7d47ff5/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld
.../rust-lld: error while loading shared libraries: libLLVM-16-rust-1.72.0-nightly.so: cannot open shared object file: No such file or directory while on this PR's $ readelf -d ~/.rustup/toolchains/6d05280785ea61c31f635fbfb61e8f988212a58b/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld | grep PATH
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../../../:$ORIGIN/../lib:/checkout/obj/build/x86_64-unknown-linux-gnu/llvm/lib]
$ ldd ~/.rustup/toolchains/6d05280785ea61c31f635fbfb61e8f988212a58b/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld | grep LLVM
libLLVM-16-rust-1.72.0-nightly.so => /home/lqd/.rustup/toolchains/6d05280785ea61c31f635fbfb61e8f988212a58b/lib/rustlib/x86_64-unknown-linux-gnu/bin/../../../libLLVM-16-rust-1.72.0-nightly.so (0x00007fffeea00000)
$ ~/.rustup/toolchains/6d05280785ea61c31f635fbfb61e8f988212a58b/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld
lld is a generic driver.
Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-ld (WebAssembly) instead so we should be good to go here. r? bootstrap |
@bors r+ |
…iaskrgr Rollup of 3 pull requests Successful merges: - rust-lang#112247 (rust-lld: add rpath entry to the correct `lib` folder) - rust-lang#112274 (Migrate GUI colors test to original CSS color format) - rust-lang#112277 (Don't require the output from libtest to be valid UTF-8) Failed merges: - rust-lang#112251 (rustdoc: convert `if let Some()` that always matches to variable) r? `@ghost` `@rustbot` modify labels: rollup
💥 Test timed out |
An explanation, for our linux rustup toolchain:
lld
/rust-lld
is built as a regular LLVM tool, but is not distributed via thellvm-tools
component. It's distributed by default, like a regular rust binary, like cargo and rustc. The general expected setup is: binaries inbin
and libraries inlib
, so the rpath we use for abin/$executable
is$ORIGIN/../lib
.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/
.$root/lib
, causing rust-lld doesn't work on Linux unless executed with rustup wrapper #80703. (LLVM's shared library is also copied to$root/lib/rustlib/$host/lib/
with thellvm-tools
component, so it also was a workaround for the issue)rustup's
LD_LIBRARY_PATH
overrides made this discrepancy invisible when we switched tollvm.link-shared = true
, and this only showed up when runningrustc
orrust-lld
's executables directly.To fix this we could:
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.)