[rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

Ben Gamari bgamari.foss at gmail.com
Wed Jul 9 13:11:07 PDT 2014

Brian Anderson <banderson at mozilla.com> 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


- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140709/d3e9374a/attachment.sig>

More information about the Rust-dev mailing list