Repository navigation
Building Rust with rpath disabled causes ~3k test failures in Cargo #140299
Description
Summary
When building Rust with rpath disabled (using --disable-rpath), the majority of Cargo tests fail due to a missing librustc_driver:
rustc: error while loading shared libraries: librustc_driver-9ac9395edaaccddf.so: cannot open shared object file: No such file or directory
Fedora disables rpath in its builds, and this has not been an issue up to Rust 1.86.0, since the bootstrap process correctly passed the appropriate LD_LIBRARY_PATH. We started encountering failures while preparing builds for the 1.87.0 beta.
I was able to reproduce and bisect the issue using a clean repository with the following script:
#!/bin/bash
./configure --disable-rpath
python x.py test cargo --test-args "run::simple"
Using this, I traced the regression to the following PR: #137215
From inspecting the output of x.py test -vv, it seems the issue is related to the combination of how LD_LIBRARY_PATH is set by bootstrap and possibly some cleanup logic. I wasn't able to fully trace the exact logic, but here are my observations.
Before that PR, Cargo tests were run using the stage 2 compiler, and the library path passed by bootstrap was:
<builddir>/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib
This directory does include the librustc_driver dynamic library.
After the PR, the compiler being used is now stage 1, as indicated by bootstrap logs such as:
c Sysroot { compiler: Compiler { stage: 1, host: x86_64-unknown-linux-gnu }, force_recompile: false }
The library path passed now is:
<builddir>/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib
But in this case, the test errors with:
rustc: error while loading shared libraries: librustc_driver-27eeeb8eb941569f.so: cannot open shared object file: No such file or directory
If I search for that library, I can find it in several locations, but not in the path that bootstrap passes:
$ find . -name librustc_driver-27eeeb8eb941569f.so
./build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_driver-27eeeb8eb941569f.so
./build/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-27eeeb8eb941569f.so
./build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_driver-27eeeb8eb941569f.so
As a workaround, the tests can be run successfully using:
LD_LIBRARY_PATH=$PWD/build/host/stage1/lib python x.py test cargo
However, I believe this behavior deserves closer attention from the bootstrap team. It's possible that the stage 1 switch introduced an unintended change in how the dynamic libraries are located, especially when rpath is disabled.
Let me know if you need help reproducing the issue in a clean environment.
When building Rust with --disable-rpath, most Cargo tests fail due to missing dynamic libraries, notably librustc_driver. This started happening after PR #137215, which changed Cargo to use the stage1 compiler instead of stage2 during tests. The bootstrap no longer passes the correct LD_LIBRARY_PATH for the dynamic libraries in this configuration, breaking Fedora builds (which disable rpath).
Command used
./configure --disable-rpath
python x.py test cargo --test-args "run::simple"Expected behaviour
Cargo tests are run without rustc reporting any missing dynamic libraries
Actual behaviour
+3000 cargo test failures due to missing rustc_driver dynamic library
rustc: error while loading shared libraries: librustc_driver-9ac9395edaaccddf.so: cannot open shared object file: No such file or directory
Bootstrap configuration (bootstrap.toml)
profile = 'dist'
[llvm]
[build]
# Arguments passed to the `./configure` script, used during distcheck. You
# probably won't fill this in but rather it's filled in by the `./configure`
# script. Useful for debugging.
configure-args = ['--disable-rpath']
[install]
[rust]
# By default the `rustc` executable is built with `-Wl,-rpath` flags on Unix
# platforms to ensure that the compiler is usable by default from the build
# directory (as it links to a number of dynamic libraries). This may not be
# desired in distributions, for example.
rpath = false
[target.x86_64-unknown-linux-gnu]
[dist]Operating system
Fedora 43 Rawhide (reproducible on a clean environment)
HEAD
Also reproducible on current beta (386abeb) and master(7f69523) branches.
Additional context
Build Log
<log>
Activity
cuviper commentedon Apr 30, 2025
Here's a little more output:
That comes from here:
https://github.com/rust-lang/cargo/blob/d811228b14ae2707323f37346aee3f4147e247e6/crates/cargo-test-support/src/lib.rs#L1303-L1306
Note that this is not using
RUSTC, which would be bootstrap's wrapper that setsLD_LIBRARY_PATH, but just plain"rustc"as whatever it finds first in thePATH-->stage1/bin/rustc. And then without rpath orLD_LIBRARY_PATH, this fails to find itslibrustc_driver.so.onur-ozkan commentedon May 1, 2025
Couldn't reproduce this on 6e23095 with the following config:
cuviper commentedon May 1, 2025
I just tried a clean build with your config on that commit, only changing the llvm-config path, and
./x test cargo --test-args run::simplestill hitserror while loading shared libraries: librustc_driver-d19119ddafb06e20.so.onur-ozkan commentedon May 1, 2025
Maybe it was due to my existing build cache, will try it again later tomorrow.
Rollup merge of rust-lang#140563 - onur-ozkan:extend-dylib-paths, r=j…
Rollup merge of rust-lang#140563 - onur-ozkan:extend-dylib-paths, r=j…
Unrolled build for rust-lang#140563