rustbuild: rpath=false does not work, maybe because `build-script-build` bypasses `rustc.rs` wrapper

[infinity0]

When experimenting with rpath = false in config.toml for rustbuild:

     Running `/rust.git/build/x86_64-unknown-linux-gnu/stage1-rustc/release/build/pulldown-cmark-efa2881d679d19c8/build-script-build`
error: failed to run custom build command for `pulldown-cmark v0.0.14`
process didn't exit successfully: `/rust.git/build/x86_64-unknown-linux-gnu/stage1-rustc/release/build/pulldown-cmark-efa2881d679d19c8/build-script-build` (exit code: 127)
--- stderr
/rust.git/build/x86_64-unknown-linux-gnu/stage1-rustc/release/build/pulldown-cmark-efa2881d679d19c8/build-script-build: error while loading shared libraries: libstd-61d72c8bf510b9ba.so: cannot open shared object file: No such file or directory

Build failed, waiting for other jobs to finish...
error: build failed

Setting LD_LIBRARY_PATH seems to fix things:

$ ./build/x86_64-unknown-linux-gnu/stage1-rustc/release/build/pulldown-cmark-efa2881d679d19c8/build-script-build
./build/x86_64-unknown-linux-gnu/stage1-rustc/release/build/pulldown-cmark-efa2881d679d19c8/build-script-build: error while loading shared libraries: libstd-61d72c8bf510b9ba.so: cannot open shared object file: No such file or directory
exit code 127
$ LD_LIBRARY_PATH=$PWD/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/ ./build/x86_64-unknown-linux-gnu/stage1-rustc/release/build/pulldown-cmark-efa2881d679d19c8/build-script-build
exit code 0

I had a poke around the code and it seems that rustbuild does make some attempt to set LD_LIBRARY_PATH here however this is not affecting the build-script-build stuff apparently.

This is also causing --no-fail env to be ineffective for this case, presumably because build-script-build also bypasses rustbuild's rustc.rs wrapper (which is the only place that actually does anything in reaction to --no-fail.

[infinity0]

Oh, this is in combination with -Cprefer-dynamic; OTOH rpath = false appears to work by itself at least. I will experiment with moving the dylib_path_var logic to lib.rs or something.

[o01eg]

Have been #43694 fix this issue?

[jyn514]

@infinity0 are you still running into this issue?