There's a fix for make install waiting on bors right now: https://github.com/rust-lang/rust/pull/15550
Steven Fackler On Wed, Jul 9, 2014 at 1:11 PM, Ben Gamari <[email protected]> wrote: > Brian Anderson <[email protected]> writes: > > > Hi. > > > > Very soon now the way rustc links crates dynamically is going to > > change[1], and it will impact the way you work with Rust in some > > important cases. The TL;DR is that rustc will no longer encode RPATH > > information in the binaries it produces, so the dynamic linker will be > > less likely to find the dynamic library (.so, .dylib) dependencies; in > > some scenarios people will need to use LD_LIBRARY_PATH or rely on > > higher-level tooling to arrange for libraries to be discovered by the > > dynamic linker at runtime. > > > Perhaps I'm missing something obvious here, but this broke `make > install` in the rustc tree for me. The cause appears to be that `make > install` tries to verify that it can run the new `rustc` binary in > place, which expectedly fails due to missing libraries, > > /opt/exp/rust $ make install > ... > install: verifying platform can run binaries > /opt/exp/rust/tmp/dist/rust-0.11.0-x86_64-unknown-linux-gnu/bin/rustc: > error while loading shared libraries: libnative-4e7c5e5c.so: cannot open > shared object file: No such file or directory > install: error: can't execute rustc binary on this platform > make: *** [install] Error 1 > > Surely I don't need to mangle LD_LIBRARY_PATH just to run `make > install`? > > Cheers, > > - Ben > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
