Respect RUSTC_LINK_STD_INTO_RUSTC_DRIVER=0 in link_std_into_rustc_driver

[DeepeshWR]

This patch allows users to opt out of statically linking std into rustc_driver by setting the existing environment variable RUSTC_LINK_STD_INTO_RUSTC_DRIVER=0.

• If the variable is unset or set to any other value, the function falls back to the default behavior (linking std on all platforms except Windows).

• Note: This does not introduce a new environment variable; it only respects an existing one.

• Defaults remain unchanged, so normal builds are unaffected.

Example usage:

export RUSTC_LINK_STD_INTO_RUSTC_DRIVER=0
./x.py build

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: bootstrap
• bootstrap expanded to 6 candidates
• Random selection from Mark-Simulacrum, clubby789, jieyouxu

[bjorn3]

This should probably be an option in bootstrap.toml rather than an env var.

Note: This does not introduce a new environment variable; it only respects an existing one.

The existing env var is just an implementation detail of how the main bootstrap executable and the rustc wrapper of bootstrap communicate.

[DeepeshWR]

This should probably be an option in bootstrap.toml rather than an env var.

Note: This does not introduce a new environment variable; it only respects an existing one.

The existing env var is just an implementation detail of how the main bootstrap executable and the rustc wrapper of bootstrap communicate.

Hi @bjorn3,
Thanks for the suggestion.
I’ve updated the patch as follows:

diff --git a/src/bootstrap/src/core/builder/mod.rs b/src/bootstrap/src/core/builder/mod.rs
index ae91b204062..b444952d16d 100644
--- a/src/bootstrap/src/core/builder/mod.rs
+++ b/src/bootstrap/src/core/builder/mod.rs
@@ -1125,6 +1125,10 @@ fn run_step_descriptions(&self, v: &[StepDescription], paths: &[PathBuf]) {
     /// Returns if `std` should be statically linked into `rustc_driver`.
     /// It's currently not done on `windows-gnu` due to linker bugs.
     pub fn link_std_into_rustc_driver(&self, target: TargetSelection) -> bool {
+        // Respect bootstrap.toml override if provided
+        if let Some(value) = self.config.link_std_into_rustc_driver {
+            return value;
+        }
         !target.triple.ends_with("-windows-gnu")
     }

diff --git a/src/bootstrap/src/core/config/config.rs b/src/bootstrap/src/core/config/config.rs
index 17f256188e1..3bd01c0f7b2 100644
--- a/src/bootstrap/src/core/config/config.rs
+++ b/src/bootstrap/src/core/config/config.rs
@@ -282,6 +282,7 @@ pub struct Config {
     pub windows_rc: Option<PathBuf>,
     pub reuse: Option<PathBuf>,
     pub cargo_native_static: bool,
+    pub link_std_into_rustc_driver: Option<bool>,
     pub configure_args: Vec<String>,
     pub out: PathBuf,
     pub rust_info: channel::GitInfo,
@@ -485,6 +486,7 @@ pub(crate) fn parse_inner(
             sanitizers: build_sanitizers,
             profiler: build_profiler,
             cargo_native_static: build_cargo_native_static,
+            link_std_into_rustc_driver: build_link_std_into_rustc_driver,
             low_priority: build_low_priority,
             configure_args: build_configure_args,
             local_rebuild: build_local_rebuild,
@@ -1364,6 +1366,7 @@ pub(crate) fn parse_inner(
             libdir: install_libdir.map(PathBuf::from),
             libgccjit_libs_dir: gcc_libgccjit_libs_dir,
             library_docs_private_items: build_library_docs_private_items.unwrap_or(false),
+            link_std_into_rustc_driver: build_link_std_into_rustc_driver,
             lld_enabled,
             lldb: build_lldb.map(PathBuf::from),
             llvm_allow_old_toolchain: llvm_allow_old_toolchain.unwrap_or(false),
diff --git a/src/bootstrap/src/core/config/toml/build.rs b/src/bootstrap/src/core/config/toml/build.rs
index 27bf753f691..042f1216ac7 100644
--- a/src/bootstrap/src/core/config/toml/build.rs
+++ b/src/bootstrap/src/core/config/toml/build.rs
@@ -52,6 +52,7 @@ struct Build {
         sanitizers: Option<bool> = "sanitizers",
         profiler: Option<bool> = "profiler",
         cargo_native_static: Option<bool> = "cargo-native-static",
+        link_std_into_rustc_driver: Option<bool> = "link-std-into-rustc-driver",
         low_priority: Option<bool> = "low-priority",
         configure_args: Option<Vec<String>> = "configure-args",
         local_rebuild: Option<bool> = "local-rebuild",

Is this what you were suggesting ?

[Mark-Simulacrum]

What is the motivation for the override of the default logic?

[DeepeshWR]

src/bootstrap/src/core/builder/mod.rs

Hi @Mark-Simulacrum ,

The main motivation is to allow builders to explicitly control whether
std is statically linked into rustc_driver, rather than relying
solely on the platform-based default.

This became important when running ./x.py test for cross targets
(e.g., under QEMU). Previously, rustc_main only depended on libstd*.so,
but after commit ,it depends on librustc_driver*.so when std is
statically linked into rustc_driver. Bootstrap removes libstd*.so in that
case, which changes the runtime dependencies during test execution. On
constrained targets (e.g., 32-bit PowerPC mac99 QEMU with 768 MB RAM),
the large size difference between libstd (~1.8 MB) and
librustc_driver (~216 MB) can cause failures.

Currently, this behavior is controlled only by the platform check
(!windows-gnu). As Bjorn suggested, introducing a bootstrap.toml
option allows builders to override it while keeping the existing default
behavior unchanged. In our use case, this option will be disabled during
tests, but for regular builds it will follow the default.

[bjorn3]

Previously, rustc_main only depended on libstd*.so,

Rustc has always been dynamically linking rustc_driver.so. It can't be statically linked without breaking custom codegen backends. What other kinds of patches have you been applying to statically link rustc_driver?

[DeepeshWR]

Previously, rustc_main only depended on libstd*.so,

Rustc has always been dynamically linking rustc_driver.so. It can't be statically linked without breaking custom codegen backends. What other kinds of patches have you been applying to statically link rustc_driver?

Previously, rustc_main only depended on libstd*.so,

Rustc has always been dynamically linking rustc_driver.so. It can't be statically linked without breaking custom codegen backends. What other kinds of patches have you been applying to statically link rustc_driver?

Just to clarify, I’m not referring to the actual rustc compiler binary.
As you mentioned, before the commit it depended on both librustc_driver*.so
and libstd*.so,and after the commit it depends only on librustc_driver*.so.

The change we’re discussing affects the rustc_main-* test binaries built
during ./x.py test (for example,build/.../release/deps/rustc_main-<hash>).
These are unit test binaries for src/main.rs, which previously depended only
on libstd*.so.

For example:

Before the commit:

$ ldd rustc_main-f93eaead863ec79c
    libstd-486d6b01362fa55f.so

After the commit:

$ ldd rustc_main-c6880500809c5c70
    librustc_driver-c3a98dd5eca12f41.so

Since std is now statically linked into rustc_driver, the runtime
dependency of these rustc_main test binaries shifts from libstd
to librustc_driver, which is the context for the issue described earlier.

[bjorn3]

rustc_main doesn't contain any test code. Just skip it. Or you could probably add #[cfg(not(test))] to fn main to avoid rustc_main depending on rustc_driver.

[jieyouxu]

(Since you're already looking at it)
r? Mark-Simulacrum

[Mark-Simulacrum]

Seems like this needs some work (or maybe isn't needed at all?) per comments, so setting to waiting on author

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.