-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rust-lld: add rpath entry to the correct lib
folder
#112247
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.)