Cannot open shared object file libstd.so, in bin crate that transitively depends on libproc_macro

[dtolnay]

When building a binary crate with a transitive dependency on libproc_macro, cargo run is able to run successfully but the resulting binary cannot be run directly.

Repro script

#!/bin/bash

set -x

cargo new repro --bin
echo >repro/src/main.rs "extern crate proc_macro; fn main() {}"
cargo build --manifest-path repro/Cargo.toml

# succeeds
cargo run --manifest-path repro/Cargo.toml

ldd repro/target/debug/repro

# fails
repro/target/debug/repro

Output

+ cargo new repro --bin
     Created binary (application) `repro` project
+ echo 'extern crate proc_macro; fn main() {}'
+ cargo build --manifest-path repro/Cargo.toml
   Compiling repro v0.1.0
    Finished dev [unoptimized + debuginfo] target(s) in 0.34 secs
+ cargo run --manifest-path repro/Cargo.toml
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `repro/target/debug/repro`
+ ldd repro/target/debug/repro
	linux-vdso.so.1 =>  (0x00007ffe8b1c2000)
	libstd-3643da641776cd22.so => not found
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5dfe77f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5dfed4c000)
+ repro/target/debug/repro
repro/target/debug/repro: error while loading shared libraries: libstd-3643da641776cd22.so: cannot open shared object file: No such file or directory

In this minimized repro, the bin crate depends directly on libproc_macro. As reported in dtolnay/indoc#15, this also fails if libproc_macro is a dependency of a dependency (proc-macro-hack) of a dependency (indoc) of a dependency (lasso), which is more realistic.

@glennpierce

[alexcrichton]

This is sort of to be expected, and there's not really anything we can do about it. When running through cargo/rustup we can manage lookup paths, but otherwise the generated binary has no way of finding the libraries itself :(

[dtolnay]

Thanks, I see why that goes wrong. I will try to work around it.

[drozdziak1]

@alexcrichton I'm experiencing a similar issue during a cross-build but not when compiling for the host (the libstd-something.so lib isn't showing up in ldd my_binary anymore). Is there a recommended workaround strategy?

[drozdziak1]

@dtolnay I've found your workaround. Does it eliminate the libstd-something.so lib from ldd output?
dtolnay/indoc@ac5c069

[alexcrichton]

@drozdziak1 that likely indicates that the proc_macro crate (through this crate) was accidentally linked in, but in general it shouldn't be linked into final applications, just procedural macros.

[nvonbulow]

@alexcrichton it may be desirable to have cargo copy libstd-x.so to the target output in the same directory as the binary, That way, libstd can be directly distributed with the application if needed instead of having to run through cargo or copy the dylib from the toolchain path directly