etc: Fix install script for rpath removal

[alexcrichton]

This adds detection of the relevant LD_LIBRARY_PATH-like environment variable
and appropriately sets it when testing whether binaries can run or not.
Additionally, the installation prints a recommended value if one is necessary.

Closes #15545

[pnkfelix]

This is a good idea, but it does not solve the problem for make install itself.

The reason: The technique that it is using to test whether an installed rustc works or not will be tricked by the build directory itself into thinking that the installed rustc can run, but in fact the needed dependencies are being resolved (at least on Mac OS X), by looking in the local directory and finding the needed libraries there.

The subtle detail here that I am trying to stress is that when the current working directory is the build directory, then all the build products work, despite being moved to the target install directory.

(The observation in the prior paragraph strikes me as a potential footgun, potentially worse than rpath itself; I do not understand the logic that the dynamic library loader is using. Maybe we should be using absolute paths rather than relative ones in the binary that we emit?)

Anyway, here is the transcript:

https://gist.github.com/pnkfelix/8cfa7a8506023f7f1154

In particular, compare this line:
https://gist.github.com/pnkfelix/8cfa7a8506023f7f1154#file-gistfile1-txt-L26
to this line:
https://gist.github.com/pnkfelix/8cfa7a8506023f7f1154#file-gistfile1-txt-L31

(where in the latter all I did was move the current working directory up to the parent of the build tree.)

---

And of course, note that when I ran make install itself, there was no warning at the end telling me that the installed build products would not actually work without changes to my env vars, as shown here:
https://gist.github.com/pnkfelix/8cfa7a8506023f7f1154#file-gistfile1-txt-L324

---

Again, I approve of the spirit of this patch, and was close to r+'ing it on that basis. But at this point it does not solve the problem at hand.

[alexcrichton]

This is needed to unblock a snapshot, it may lead to not printing something on OSX, but this is holding back the linux snapshot if it doesn't get merged.

[brson]

In @pnkfelix's first example, I don't understand why rustc links correctly when running out of the build directory.

[alexcrichton]

It appears that OSX has a hardcoded path to the library as the last fallback:

$ otool -l x86_64-apple-darwin/stage2/bin/rustc 
...
Load command 27
          cmd LC_LOAD_DYLIB
      cmdsize 112
         name x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustrt-4e7c5e5c.dylib (offset 24)
   time stamp 2 Wed Dec 31 16:00:02 1969
      current version 0.0.0
compatibility version 0.0.0
...

I believe it's using these hardcoded paths as the last fallback because nothing is found in DYLD_LIBRARY_PATH

[netvl]

Linux nightly still does not compile with an error about libnative :( http://buildbot.rust-lang.org/builders/nightly-linux/builds/28 It fails on distcheck.

[alexcrichton]

That should be fixed by #15578