`make install` (to non-standard prefix) is failing

[chris-morgan]

$ make install
…
install: validating tmp/dist/rust-0.11.0-x86_64-unknown-linux-gnu/install.sh args
install: 
install: verifying platform can run binaries
/home/chris/rust/tmp/dist/rust-0.11.0-x86_64-unknown-linux-gnu/bin/rustc: error while loading shared libraries: librustc-4e7c5e5c.so: cannot open shared object file: No such file or directory
install: error: can't execute rustc binary on this platform
/home/chris/rust/mk/install.mk:18: recipe for target 'install' failed
make: *** [install] Error 1

At this point, /home/chris/rust/tmp/dist/rust-0.11.0-x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.so and /home/chris/rust/tmp/dist/rust-0.11.0-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.so both exist.

Just in case it matters: my prefix is /home/chris/opt/rust.

[chris-morgan]

Fallout from #14832, perhaps?

This isn’t the first time we’ve had make install completely broken (two months ago it happened, #14033). Why don’t we add it to the tests done on the buildbot?

[pnkfelix]

Indeed, this was predicted as a known consequence of #14832.

It may be the case that asking people to set LD_LIBRARY_PATH is too much. We might need/want wrapper scripts to drive rustc that set up such environment variables, much like other projects have.

[alexcrichton]

Fixed by #15550.

[pnkfelix]

(see comment #15550 (comment) , since it is relevant to this issue.)