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.

[brooksbp]

As a newcomer to hacking on Rust, I lost a lot of time due to this particular issue. After receiving --enable-rpath enlightenment I decided to rework the Downloading and Building Rust section of the wiki hoping that it will help other newcomers. I welcome feedback on the edits.

Also, someone on IRC mentioned that using --enable-rpath breaks cargo builds. Appreciate it if someone could shed more light on what this really means, and how causes the breakage.

Thanks!

[kmcallister]

What I mentioned on IRC is that projects which use Cargo build scripts (i.e. build.rs) will hit a dynamic linker error trying to run the Rust program resulting from compiling the build script. I guess that's because Cargo isn't using rustc -C rpath.

It does seem weird to have two options for how to find dynamic libraries. I'm okay sticking to LD_LIBRARY_PATH if that's the simple solution. This is a long-standing problem on UNIX and not one we're likely to solve in a breakthrough way. afaik a lot of projects would use a shell script named rustc that figures out the right variables and invokes rustc.bin.

[pnkfelix]

afaik a lot of projects would use a shell script named rustc that figures out the right variables and invokes rustc.bin

Indeed I have often wondered why we have not simply embraced this approach ourselves; i.e. provide a pair of such wrapper scripts (a sh script for unix, and a .bat batch file for windows). If we don't then I assume that people will just roll their own... might as well have a standard one for everyone to use ...

update: indeed, I already mentioned this a few months ago here: #19263 (comment)

[paulp]

I am doubtful about the logic being used to justify pushing the matter of creating a runnable program onto individual developers. I would say it is squarely in the range of what people expect their compilers to do.

It's a pretty awful first impression of rust to install anywhere but /usr/local on OSX and discover nothing works. Even if shipped, wrappers which set environment variables are suboptimal in numerous ways: you need one for every program until the end of time (e.g. people think of rustc, but I haven't seen anyone mention rustdoc, which requires the same treatment), it doesn't compose, it's racy, error messages are opaque, a dependency on the contents of an unsynchronized mutable unrestricted namespace is vulnerable to interference (intentional or not) by anything else in the system, the list goes on and on.

% ~/.multirust/toolchains/beta/bin/rustc
dyld: Library not loaded: x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc_driver-e4d77fca.dylib
  Referenced from: /Users/paulp/.multirust/toolchains/beta/bin/rustc
  Reason: image not found
Trace/BPT trap: 5 (core dumped)

% ~/.multirust/toolchains/beta/bin/rustdoc
dyld: Library not loaded: x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustdoc-e4d77fca.dylib
  Referenced from: /Users/paulp/.multirust/toolchains/beta/bin/rustdoc
  Reason: image not found
Trace/BPT trap: 5 (core dumped)

See #19263 (comment) for more.

[paulp]

Here is a very helpful gist (I'm not the author, I just cloned it to make sure it would stick around) enumerating some of the failure modes of DYLD_* .

[alexcrichton]

Closing since we enabled rpath by default