Unable to execute a hello world project when using prefer-dynamic

I'm playing with Rust's compilation options on an extremely simple project, hello world:

fn main() {
    println!("Hello, world!");
}

I'm compiling with this line, prefer-dynamic is the only notable option:

rustc main.rs -o ./build/rci -C prefer-dynamic

It was working fine until I made some changes and then it didn't. Now if I try to compile the code exactly as above I get this output:

./build/rci: error while loading shared libraries: libstd-2ddb28df747fcb8c.so: cannot open shared object file: No such file or directory

The output of ldd is:

linux-vdso.so.1 =>  (0x00007ffd321a4000)
libstd-2ddb28df747fcb8c.so => not found
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f52eaef3000)
/lib64/ld-linux-x86-64.so.2 (0x000055f0f6251000)

This is on Ubuntu 17.04 with Rust 1.15.1.

You should review your terminology; words mean specific things when programming. You are able to compile your code just fine, as shown by the fact that invoking the Rust compiler (a.k.a. rustc) doesn't have any errors.

Your problem occurs when executing the program. These are very different concepts and it will serve you well to understand the difference.

The "problem" is that you... are using dynamic linking, just like you've asked for. This is not a Rust issue, just a general programming issue. I'm sure there are numerous SO questions, such as Linux error while loading shared libraries: cannot open shared object file: No such file or directory or one of the 500 other questions with that error message that can provide you with more information.

You are dynamically linking against the Rust standard library, but your system doesn't know about that library because it's not installed in a location your system knows about. Most likely, you've installed via rustup, so the library is in your home directory. For example, mine is in /home/ubuntu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/libstd-f4594d3e53dcb114.so.

You will find many possible solutions. The easiest to demonstrate is using the LD_LIBRARY_PATH variable:

$ ./example
./example: error while loading shared libraries: libstd-f4594d3e53dcb114.so: cannot open shared object file: No such file or directory
$ LD_LIBRARY_PATH=/home/ubuntu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/ ./example
Hello, world!

You can also check out Linking Rust application with a dynamic library not in the runtime linker search path

To help discover this, you can make Rust print out the linker invocation it uses:

$ rustc +nightly -Cprefer-dynamic -Z print-link-args hello.rs
"cc" "-m64" "-L" "/Users/shep/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "hello.hello0.rcgu.o" "hello.hello1.rcgu.o" "hello.hello2.rcgu.o" "hello.hello3.rcgu.o" "hello.hello4.rcgu.o" "hello.hello5.rcgu.o" "-o" "hello" "hello.crate.allocator.rcgu.o" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/shep/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "-L" "/Users/shep/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "-l" "std-834fbefe8dbe98b5" "/Users/shep/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-b4312e2f1496a4e4.rlib" "-l" "System" "-l" "resolv" "-l" "pthread" "-l" "c" "-l" "m"

You can see that "-L" "/Users/shep/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" was added to the linker path and then "-l" "std-834fbefe8dbe98b5" links the standard library.

Recommended topics

Hot tags