Building Rust with rpath disabled causes ~3k test failures in Cargo

[jchecahi]

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

bb2cc59

Also reproducible on current beta (386abeb) and master(7f69523) branches.

Additional context

Build Log

<log>

[cuviper]

Here's a little more output:

---- run::simple stdout ----

thread 'run::simple' panicked at src/tools/cargo/crates/cargo-test-support/src/lib.rs:1306:14:
rustc should exec: process didn't exit successfully: `rustc -vV` (exit status: 127)
--- stderr
rustc: error while loading shared libraries: librustc_driver-5ff98ba4c642832b.so: cannot open shared object file: No such file or directory

That comes from here:
https://github.com/rust-lang/cargo/blob/d811228b14ae2707323f37346aee3f4147e247e6/crates/cargo-test-support/src/lib.rs#L1303-L1306

        let output = ProcessBuilder::new("rustc")
            .arg("-vV")
            .exec_with_output()
            .expect("rustc should exec");

Note that this is not using RUSTC, which would be bootstrap's wrapper that sets LD_LIBRARY_PATH, but just plain "rustc" as whatever it finds first in the PATH --> stage1/bin/rustc. And then without rpath or LD_LIBRARY_PATH, this fails to find its librustc_driver.so.

[onur-ozkan]

Couldn't reproduce this on 6e23095 with the following config:

 profile = "dist"

 [llvm]
 download-ci-llvm = false

 [rust]
 lld = false
 rpath = false

 [target.x86_64-unknown-linux-gnu]
 llvm-config = "/home/nimda/devspace/.other/llvm-19/bin/llvm-config"

[cuviper]

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::simple still hits error while loading shared libraries: librustc_driver-d19119ddafb06e20.so.

[onur-ozkan]

Maybe it was due to my existing build cache, will try it again later tomorrow.