Set -Wl,-rpath,'$ORIGIN/../lib' when building rust toolchain

[rillian]

For building rust code in automation, it would be convenient if the official builds of rustc, rustdoc, cargo, etc. set an rpath relative to the executable, so they can be invoked without having to add to LD_LIBRARY_PATH (linux) or DYLD_LIBRARY_PATH (mac).

[rillian]

Note in particular I'm having trouble getting the LD_LIBRARY_PATH thing to work in gecko automation. Fragile build systems.

[pnkfelix]

@rillian have you tried passing --enable-rpath to the configure script when building rustc ?

In short, We used to do this, and we explicitly stopped doing it, for various reasons.

See in particular the discussion at #14832

update: see also discussion at old weekly mtg: https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-07-08.md#rpath

[rillian]

For docs, if like me, you'd never heard of $ORIGIN, see http://man7.org/linux/man-pages/man8/ld.so.8.html#DESCRIPTION and https://developer.apple.com/library/prerelease/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html

glandium adds that Firefox uses @executable_path. https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html

[pnkfelix]

@rillian (if you have a counter-argument to the claims that "There are also bad things with rpaths. [Linux] distros will reject binaries that have rpaths" from the notes above, I would be curious to hear them. I had tried to push back against this change back when it was put forward, but I am ignorant of distros' processes and thus decided that I could not argue effectively on that front.)

[rillian]

@pnkfelix Thanks. I didn't know about --enable-rpath That should fix the issue, but is another step away from being able to use official builds.

The bug discussion mostly seems to be about rpath in rustc's output. I'm just asking for it in rustc itself. Changing the default of the configure switch, not of -C rpath if I understand correctly.

[glandium]

What is the rationale for the rustc builds one can download are not using --enable-rpath? They are the builds that would benefit from it the most...

[pnkfelix]

see also #21483 #28640

[larsbergstrom]

CC @alexcrichton @brson

[alexcrichton]

The past motivations for this change are outlined in the many linked issues here (I'll also throw in #11747).

It seems fine, however, to enable this sort of setting by default when building the compiler itself (but not for the executables the compiler itself then generates). I don't think we can "just use" the -C rpath option as it's not quite what we want for our own distribution, so this will likely either passing weird -C link-args or using external tools to frob these settings after the artifacts are built.

[brson]

Not sure I agree that it's fine for the rustc case. The main argument seems the same to me there - it's different than windows.

[alexcrichton]

I guess you can view this from two angles:

• On one hand rpath doesn't exist on Windows but does on Unix
• On the other hand the compiler works by default on Windows but doesn't work on Unix

I'd probably lean more towards consistency on the latter point for the compiler itself at least.

[jonthn]

I would love a variant of this for OSX (using @executable_path also explained in a few other issues) . It would mean I don't have to mess around with DYLD_LIBRARY_PATH and I can use --prefix= of rustup.sh

Also I believe this change would help integration with package systems for open-source OSes.