rustc should be usable as-is from the build directory

[SimonSapin]

Steps to reproduce:

• Clone this git repository
• Run ./configure && make
• Run x86_64-unknown-linux-gnu/stage2/bin/rustc --help

Expected results: the help message. rustc can be used in place to compile stuff.

Actual result:

x86_64-unknown-linux-gnu/stage2/bin/rustc: symbol lookup error: x86_64-unknown-linux-gnu/stage2/bin/rustc: undefined symbol: _ZN2rt10lang_start20h8e79fc6788a362d0mJzE

The instructions in README.md also include make install which would fix this issue, but:

• make install defaults to writing to a directory that typically requires root access
• I might already have a (potentially different) version of Rust installed system-wide.

I’m told I can pass --enable-rpath to ./configure, but that’s exactly the kind of secret sauce that I shouldn’t need to know.

Possible solutions:

• Make --enable-rpath the default for source builds (binary builds distributed on rust-lang.org don’t have to use that default)
• Make bin/rustc a wrapper script that sets the correct environment variables (e.g. LD_LIBRARY_PATH on Linux). This might also help with Support installing multiple release channels #19263.

CC @brson

[nagisa]

Another possible solution:

• Just link everything to rustc statically.

[kmcallister]

I use ./configure --enable-rpath but I too would like a better solution. iirc it was the default at some point in the past.

[tdaede]

Why does this error give an undefined symbol error rather than a "cannot load shared library" type of error, which would be the case if it couldn't find the libraries? In bug #21344, when I deleted the system libraries in /lib, it a missing .so error.

[taralx]

+1 to --enable-rpath being the default. My gut says that this is more likely to be a useful default than the disabled version.

[kmcallister]

It used to be the default. I don't remember why it was changed, but I think the decision has been made.

[taralx]

Apparently the rationale was "because windows doesn't support it". (see #11747)

[taralx]

It seems to me that a better answer might be to twiddle rpaths on install instead of setting them during build. That way you don't run into the "stage1 uses the wrong version" problem noted in that issue.

[lucab]

@taralx not only that, see #11746 and #5219 for more details.

[taralx]

Thanks for the background. I think I'll file a separate issue to set rpath during install.

[alexcrichton]

One thing to note is that --enable-rpath is not enough to make it work "out of the box". I personally use --enable-rpath locally but I must always remember to unset LD_LIBRARY_PATH as I have a nightly installation elsewhere which is used before the rpath listed. I think that the "solution" to this would be for the rustc file to be a script which munges LD_LIBRARY_PATH and works regardles of --enable-rpath or not.

[taralx]

On mac os you can use DYLD_FALLBACK_LIBRARY_PATH to avoid overriding rpaths. Does ld.so have something like that?

[alexcrichton]

I'm not currently aware of an equivalent on linux, but I had forgotten about that! To be maximally compatible with Windows, however, we'd likely want to not rely on these environment variables (as windows certainly doesn't have it)

[taralx]

I'm not sure you can do much on windows other than put the dlls in the same dir as the executables...

[brson]

We might first consider linking the binaries statically, since that works on windows.