Issue 1:
fn main() {
struct Example;

trait BaseTrait { fn toString(&self) -> ~str { ~"BaseTrait" } }

trait DerivedTrait : BaseTrait {
fn new() -> Self;
fn toString(&self) -> ~str { ~"DerivedTrait" }
}

impl BaseTrait for Example { }

impl DerivedTrait for Example { fn new() -> Example { Example } }

let bug: Example = DerivedTrait::new();
println(fmt!("%s", bug.toString()));
}

klutzy@#rust was kind enough to give me debug output:

$ rustc.exe --version
d:\stone\rust\build-32\i686-pc-mingw32\stage2\bin\rustc.exe 0.8-pre
host: i686-pc-mingw32

$ RUST_LOG=rustc=1 rustc.exe x.rs
x.rs:32:20: 32:32 error: multiple applicable methods in scope
x.rs:32 println(fmt!("%s", bug.toString()));
^~~~~~~~~~~~
note: in expansion of fmt!
x.rs:32:9: 32:34 note: expansion site
task <unnamed> failed at 'report_static_candidate: bad item {crate: 0, node: 120}', D:\stone\rust\src\librustc\middle\typeck\check\method.rs:1306
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug
note: try running with RUST_LOG=rustc=1 to get further details and report the results to github.com/mozilla/rust/issues
task <unnamed> failed at 'explicit failure', d:\stone\rust\src\librustc\rustc.rs:376

We thought it was related to #8808, this might be a duplicate.

Issue 2:
Let me start off by saying, any time that LD_LIBRARY_PATH must be used is a bug. Not just a user experience bug, but an absolute bug. The sole purpose of LD_LIBRARY_PATH is for local administrators to override the default for debugging or something, it must never be used by upstream or by distro, in any package. Never, ever, ever.

Now, looking at distro policies:

All setuid/setgid/setcap executables must have no relative rpaths, because the executable may be hard-linked to load arbitrary code.

There must not be absolute rpaths to the build directory after installation (relative rpaths are okay, subject to the previous rule), because unprivileged users can write to the build directory to load.

The standard directories, (/lib/, /lib64/, /usr/lib/, and /usr/lib64/), must never be specified in an rpath. (Note, however, that if you install a library to the standard paths, you must run ldconfig afterward)

It is possible to extend the list of standard directories by adding a file to /etc/ld.so.conf.d/, but this is the job of the distro, not upstream.

If a library is installed outside the standard directories (either because it is private, or because it is being installed as an unprivileged user), you must emit an rpath.

Rust can avoid the problem of .so version changes in basic library packages such as libc, simply by including the SONAME of all the system libraries in the hash (this doesn't strictly need to be done now, only if such a change happens, and could be pushed to the distros problem (there probably should be a way to specify that anyway), but it shouldn't be hard so it might as well be done now so that an answer can be given to distros who ask).

Finally, a brief mention of Windows. Prior discussion has claimed that Windows does not support rpaths, but this is missing one criticial thing: Windows binaries have a hard-coded rpath of ., because each binaries bundling its own libraries has been the normal route, not the exception.

The result of misunderstanding the implications of rpath has been much breakage, and telling users to use environment variables that are only intended for debugging.