Skip to content

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

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

Open
jchecahi opened this issue Apr 25, 2025 · 0 comments
Open

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

jchecahi opened this issue Apr 25, 2025 · 0 comments
Labels
C-bug Category: This is a bug. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Comments

@jchecahi
Copy link

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>

@jchecahi jchecahi added C-bug Category: This is a bug. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Apr 25, 2025
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Apr 25, 2025
@onur-ozkan onur-ozkan removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Apr 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

No branches or pull requests

3 participants