rustup doesn't set LD_LIBRARY_PATH

[Kingsquee]

OS: Fedora 24

Steps to reproduce:

test.rs

fn main {
  println!("foo");
}

$ rustc test.rs outputs foo $ rustc test.rs -C prefer-dynamic outputs error while loading shared libraries: libstd-f5a209a9.so: cannot open shared object file: No such file or directory

The old rust installer used system paths, which meant one could simply install rustc and away we go. Since the rustup installer became standard, any code that requires -C prefer-dynamic no longer runs out of the box, as LD_LIBRARY_PATH is not automatically updated with libstd's location.

This renders a compiler flag on the stable release channel useless, and completely breaks the idea of Stability as a Deliverable.

Rust code also just became vastly more awkward to redistribute to less experienced developers. The fact it "just works" out of the box was one of the remaining reasons I've continued using Rust - going from source code to a working application was "install compiler, compile app, enjoy". Distributing free software is actually practical with this model. If I wanted to teach people to fiddle with paths I'd use C/++.

This is obviously a very angry bug report, but I hope its importance is clear, irregardless of however marginal its use case may seem. Please feel free to tell me I pushed the wrong button or something so I can continue being happy in life.

[brson]

Thanks for the bug report @Kingsquee.

You are correct that dynamically linked libraries do not work correctly under rustup. This is an unfortunate tradeoff rustup makes to enable toolchain multiplexing. Dynamic linking in Rust is not well supported generally and is not considered a best practice today.

rustup has a workaround for this problem in that rustup run configures the environment correctly for a specific toolchain.

There is frankly no solution on the horizon to fix this problem generally.

Other single-toolchain installation methods will remain available.

[Diggsey]

@brson There is a very straight-forward solution to this problem: have cargo copy the required dynamic libraries to the output directory. (On linux the compiler may also need to set rpath to $ORIGIN as well when invoking the linker)

This solves numerous issues with dynamic linking in one go, and makes it trivial to distribute rust binaries with all required dylibs.

See: https://github.com/rust-lang/cargo/issues/3394#issuecomment-277012503

[Kingsquee]

Having a .rustup/toolchains/current dir would make rustc usable, as intended.

[Diggsey]

@Kingsquee That's not possible for multiple reasons:

1. The current toolchain is determined by many factors, including environment variables, and the current directory
2. If you were to switch toolchains, all of your rust binaries would break

[mcgoo]

rustup run sets up the dylib path for a given toolchain, so it works to use rustup run stable ./test to run the resultant binary. (rustup run could probably use a --current. )

[workingjubilee]

@rustbot label: +O-linux

[cdecompilador]

The workaround rustup run does not seem to work anymore

[kinnison]

In what way does it "not seem to work any more" ?

indolence(git)(🦀🏠)% cat > test.rs                                                                                                                                          
fn main(){println!("foo");}
indolence(git)(🦀🏠)% rustc test.rs -C prefer-dynamic                                                                                                                        
indolence(git)(🦀🏠)% ldd test                                                                                                                                               
	linux-vdso.so.1 (0x00007ffc447cd000)
	libstd-05b39ac0cb4c5688.so => not found
	libgcc_s.so.1 => /nix/store/65hafbsx91127farbmyyv4r5ifgjdg43-glibc-2.33-117/lib/libgcc_s.so.1 (0x00007f05e084d000)
	libc.so.6 => /nix/store/65hafbsx91127farbmyyv4r5ifgjdg43-glibc-2.33-117/lib/libc.so.6 (0x00007f05e0678000)
	/nix/store/65hafbsx91127farbmyyv4r5ifgjdg43-glibc-2.33-117/lib/ld-linux-x86-64.so.2 => /nix/store/65hafbsx91127farbmyyv4r5ifgjdg43-glibc-2.33-117/lib64/ld-linux-x86-64.so.2 (0x00007f05e086e000)
indolence(git)(🦀🏠)% ./test                                                                                                                                                 
./test: error while loading shared libraries: libstd-05b39ac0cb4c5688.so: cannot open shared object file: No such file or directory
zsh: exit 127   ./test
indolence(git)(🦀🏠)% rustup run stable ./test                                                                                                                               
foo
indolence(git)(🦀🏠)%