Fix run make tests when it can't find dynamically linked librustc

[aditijannu]

The recent updates to run make support caused the following tests to break on sgx i.e. target x86_64-fortanix-unknown-sgx :

11:22:48 failures:
11:22:48     [run-make] tests/run-make/CURRENT_RUSTC_VERSION
11:22:48     [run-make] tests/run-make/a-b-a-linker-guard
11:22:48     [run-make] tests/run-make/rustdoc-test-args
11:22:48     [run-make] tests/run-make/wasm-abi
11:22:48     [run-make] tests/run-make/wasm-custom-section
11:22:48     [run-make] tests/run-make/wasm-custom-sections-opt
11:22:48     [run-make] tests/run-make/wasm-export-all-symbols
11:22:48     [run-make] tests/run-make/wasm-import-module
11:22:48     [run-make] tests/run-make/wasm-panic-small
11:22:48     [run-make] tests/run-make/wasm-spurious-import
11:22:48     [run-make] tests/run-make/wasm-stringify-ints-small
11:22:48     [run-make] tests/run-make/wasm-symbols-different-module
11:22:48     [run-make] tests/run-make/wasm-symbols-not-exported
11:22:48     [run-make] tests/run-make/wasm-symbols-not-imported

The error observed was:

rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-8fd070a3dbd486b2.so: cannot open shared object file: No such file or directory

Providing the LD_LIBRARY_PATH for compiling and running the tests fixes the issue. Similar fix from the past - #113889 for a similar error.

@jethrogb @raoulstrackx

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[rustbot]

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[jieyouxu]

Hmm, I wonder if this is the right place to solve it. The original run-make specifies LD_LIBRARY_PATH via LD_LIB_PATH_ENVVAR (when that is the correct LD_LIB_PATH_ENVVAR for the target):

rust/src/tools/compiletest/src/runtest.rs

Line 3582 in 7f3a62b

.env("LD_LIB_PATH_ENVVAR", dylib_env_var())

In tools.mk, then LD_LIBRARY_PATH (which is the suitable LD_LIB_PATH_ENVVAR) is set to the correct paths

rust/tests/run-make/tools.mk

Lines 3 to 6 in 536606b

	HOST_RPATH_ENV = \
	$(LD_LIB_PATH_ENVVAR)="$(TMPDIR):$(HOST_RPATH_DIR):$($(LD_LIB_PATH_ENVVAR))"
	TARGET_RPATH_ENV = \
	$(LD_LIB_PATH_ENVVAR)="$(TMPDIR):$(TARGET_RPATH_DIR):$($(LD_LIB_PATH_ENVVAR))"

My guess is that

rust/src/tools/run-make-support/src/lib.rs

Lines 142 to 154 in 536606b

	let ld_lib_path_envvar = env::var("LD_LIB_PATH_ENVVAR").unwrap();
	let mut cmd = Command::new(bin_path);
	cmd.env(&ld_lib_path_envvar, {
	let mut paths = vec![];
	paths.push(PathBuf::from(env::var("TMPDIR").unwrap()));
	for p in env::split_paths(&env::var("TARGET_RPATH_ENV").unwrap()) {
	paths.push(p.to_path_buf());
	}
	for p in env::split_paths(&env::var(&ld_lib_path_envvar).unwrap()) {
	paths.push(p.to_path_buf());
	}
	env::join_paths(paths.iter()).unwrap()
	});

is broken, but this should be the correct place to fix it. In particular, I think you'd just need to preserve the semantics of

 HOST_RPATH_ENV = \ 
     $(LD_LIB_PATH_ENVVAR)="$(TMPDIR):$(HOST_RPATH_DIR):$($(LD_LIB_PATH_ENVVAR))" 
 TARGET_RPATH_ENV = \ 
     $(LD_LIB_PATH_ENVVAR)="$(TMPDIR):$(TARGET_RPATH_DIR):$($(LD_LIB_PATH_ENVVAR))"

[jieyouxu]

Ah, I think "TARGET_RPATH_ENV" should instead be TARGET_RPATH_DIR? Can you check if that fixes the issue?

[aditijannu]

@jieyouxu Updating TARGET_RPATH_ENV with TARGET_RAPTH_DIR doesn't work on sgx.

[jieyouxu]

Hmm nevermind then. I see the original run-make test also had this issue...

[jieyouxu]

Actually, could you try changing

- for p in env::split_paths(&env::var("TARGET_RPATH_ENV").unwrap()) { 
-     paths.push(p.to_path_buf()); 
- }
+ for p in env::split_paths(&env::var("HOST_RPATH_DIR").unwrap()) { 
+     paths.push(p.to_path_buf()); 
+ }
+ for p in env::split_paths(&env::var("TARGET_RPATH_DIR").unwrap()) { 
+     paths.push(p.to_path_buf()); 
+ }

Judging from #113889, HOST_RPATH_DIR should have the paths you need (I hope)

[Mark-Simulacrum]

Fixing this with something like this makes sense to me.

[aditijannu]

Fixed in #123763