rustc: Disable rpath settings by default

[alexcrichton]

This commit disables rustc's emission of rpath attributes into dynamic libraries
and executables by default. The functionality is still preserved, but it must
now be manually enabled via a -C rpath flag.

This involved a few changes to the local build system:

• --disable-rpath is now the default configure option
• Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH
  in order to support building rust with rust already installed.
• The compiletest program was taught to correctly pass through the aux dir as a
  component of LD_LIBRARY_PATH in more situations.

The major impact of this change is that neither rustdoc nor rustc will work
out-of-the-box in all situations because they are dynamically linked. It must be
arranged to ensure that the libraries of a rust installation are part of the
LD_LIBRARY_PATH. The default installation paths for all platforms ensure this,
but if an installation is in a nonstandard location, then configuration may be
necessary.

Additionally, for all developers of rustc, it will no longer be possible to run
$target/stageN/bin/rustc out-of-the-box. The old behavior can be regained
through the --enable-rpath option to the configure script.

This change brings linux/mac installations in line with windows installations
where rpath is not possible.

Closes #11747
[breaking-change]

[brson]

This should probably get some wider consideration before merging since it's a huge change to the way people interact with rustc.

[alexcrichton]

Perhaps an RFC should go through first?

[pnkfelix]

cc me

[pnkfelix]

Up front: I haven't looked at the patch.

From the bug description, it sounds like @alexcrichton is conflating the consequences of changing the defaults of whether rustc itself has an RPATH setting with the consequences of changing the defaults for whether rustc auto-injects an RPATH into the binaries it compiles without prompting from the end-user.

That is, the former seems to related to whether you can run $target/stageN/bin/rustc out of the box, and the latter relates to how you would go about running rustc-generated binaries (such as rustdoc) out of the box.

I suppose it is natural to conflate these things, since rustc is indeed itself a product of rustc. But nonetheless, we could deviate from the chosen default for the rustc binary itself (and only rustc itself). It's just a thought; maybe we are better off not doing that though, to ensure that users who attempt to use rust encounter this pain point as soon as they possibly can...

[brson]

Discussed at https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-07-08.md.