-C rpath does not work on OS X

[comex]

With just rustc -C prefer-dynamic test.rs, I get a binary with load commands that look like this:

          cmd LC_LOAD_DYLIB
      cmdsize 112
         name x86_64-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/lib/libnative-4e7c5e5c.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 0.0.0
compatibility version 0.0.0

This is not an absolute path, and in fact does not even exist - since I downloaded rustc from a nightly, the real path is /Users/comex/rust-nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustrt-4e7c5e5c.dylib. The pre-install path comes from that library's LC_ID_DYLIB.

The binary does not run, but so far that's expected behavior and setting DYLD_LIBRARY_PATH works. However, as far as I can tell, -C rpath is supposed to make a binary with the correct path built in. It does not. It adds a -rpath entry, but on OS X, -rpath is documented as follows:

     -rpath path
                 Add path to the runpath search path list for image being created.  At runtime, dyld uses the runpath when searching for dylibs whose load path begins with
                 @rpath/.

While LC_RPATH shows up in the binary, the LC_LOAD_DYLIB load paths are the same old x86_64-apple-darwin/etc/etc, so the rpath is not used and nothing changes.

[Nashenas88]

I'm running into this when trying to build something with the rustc_private feature. I'm using multirust, and it's currently bound to the nightly toolchain. I have the exact same output as @comex. It's impossible to proceed without rebuilding rustc from scratch.

[durka]

Confirmed here as well. It happens when trying to build rustbook as well as other things. Somehow cargo run is able to paper over the bogus library paths, but it would be nice if the binary worked on its own.

[steveklabnik]

Triage: I do not have a mac, so I cannot try to reproduce again today. Anyone?

[durka]

I don't know how to get output like what @comex pasted with the load commands. However, I have this:

Alexs-MacBook-Air-3:rust alex$ cat xx.rs
fn main() {
    println!("hi");
}

Alexs-MacBook-Air-3:rust alex$ rustc -C prefer-dynamic xx.rs
Alexs-MacBook-Air-3:rust alex$ ./xx
dyld: Library not loaded: @rpath/libstd-a38e14755045bae4.dylib
  Referenced from: /Users/alex/Programming/rust/rust/./xx
  Reason: image not found
Trace/BPT trap: 5
Alexs-MacBook-Air-3:rust alex$ otool -L xx
xx:
	@rpath/libstd-a38e14755045bae4.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
Alexs-MacBook-Air-3:rust alex$ rustc -C prefer-dynamic -C rpath xx.rs
Alexs-MacBook-Air-3:rust alex$ ./xx
hi
Alexs-MacBook-Air-3:rust alex$ otool -L xx
xx:
	@rpath/libstd-a38e14755045bae4.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

That is, -C prefer-dynamic produces a broken binary, -C rpath fixes it, but they seem to be referring to the same libs as far as otool is concerned.

[comex]

There is still weirdness in this area, but -C rpath does have an effect now, so closing.