rustup doesn't set LD_LIBRARY_PATH

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.

Start with the test.rs reproduction using rustc -C prefer-dynamic on Fedora 24, then trace how rustup exposes the installed toolchain and its shared libraries. Done means a dynamically linked program built through rustup runs without manually setting LD_LIBRARY_PATH.