Fix broken-pipe-no-ice run-make test for rpath-less builds

[jchecahi]

tests/run-make/broken-pipe-no-ice currently fails to run when rpath is disabled in bootstrap config, as the rustc and rustdoc binaries invoked cannot find the required shared libs (librustc_driver.so).

This commit manually sets the dylib search path for both commands. The logic mirrors what's implemented in run_make_support::util::set_host_compiler_dylib_path, ensuring that the host compiler’s shared libraries are available at runtime even when rpath is disabled.

This is necessary because the test manually constructs the rustc/rustdoc Command instances instead of using the run_make_support wrappers, and would otherwise lack the dynamic linker environment setup.

Fixes part of #140738

[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

[rustbot]

This PR modifies run-make tests.

cc @jieyouxu

[jieyouxu]

I feel like I wrote the initial version of this test 🤔 AFAIK, this should just use the rustc() wrapper, but at the time I don't know why I didn't use rustc() 🤔 Can you try instead just using rustc() from r-m-s that already does the host path adjustments?

[jieyouxu]

@rustbot author

[rustbot]

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

[jchecahi]

I feel like I wrote the initial version of this test 🤔 AFAIK, this should just use the rustc() wrapper, but at the time I don't know why I didn't use rustc() 🤔 Can you try instead just using rustc() from r-m-s that already does the host path adjustments?

Hi @jieyouxu, thanks for reviewing the PR!

Actually, that was the first thing I tried 🙂 — I initially attempted to use the rustc() and rustdoc() wrappers from run-make-support directly. However, the test needs to manipulate the Command (e.g., to add arguments or pipe stdout), and since the Command field in those wrappers is private, it's not accessible from the test.

Because of that, I figured the test was intentionally written using a bare Command::new(...), and I mirrored the logic of set_host_compiler_dylib_path manually instead.

Happy to explore alternatives if there's a clean way to use the wrappers here!

[jieyouxu]

D'oh right, that's why 😆

Can you try instead of reimplementing set_host_compiler_dylib_path:

• Expose the set_host_compiler_dylib_path helper and make it available for run-make tests? That way, for the tests that need to set the host dylib manually (I expect this to be very rare), they don't have to duplicate that logic?
• Add a comment to set_host_compiler_dylib_path that reminds the test writer that rustc()/rustdoc()/cargo() (after run-make-support: set rustc dylib path for cargo wrapper #140745 merges) will set this automatically, and in the general case it should not be used directly.

[jchecahi]

Right, I went ahead and tried exposing set_host_compiler_dylib_path, but ran into a type mismatch: the function expects a run_make_support::command::Command, whereas this test uses std::process::Command directly, since it needs access to stdout/stderr and to spawn() for the child process. I also tried using the run_make_support::run::cmd() wrapper, but that just moved the type mismatch error to the function, which still expects a std::process::Command. Moreover, the run_make_support::command module is private, so I couldn’t access it easily.

Maybe adapting set_host_compiler_dylib_path to work with both types could solve the issue, but honestly, it feels a bit messy just to fix this single test. I believe the manual logic, although not ideal, might still be the cleanest option in this case.

That being said, I’m happy to further discuss or explore any other suggestions you may have. Let me know what you think!

[jieyouxu]

Let me play around a bit with this locally, I'll get back to u tmrw.

[jieyouxu]

@rustbot review