Running a binary built by cargo fails due to missing libraries; but cargo running it works

[staktrace]

STR (using latest stable rust 1.23.0 on Ubuntu 16.04):

1. Clone the cbindgen repo (current master is 270491f)
2. Build it using cargo build --release
3. Run it by running target/release/cbindgen
4. Run it by running cargo run --release

Expected:
step 3 and step 4 both run the binary without errors

Actual:
Step 4 runs the binary. But step 3 produces this error:

target/release/cbindgen: error while loading shared libraries: libproc_macro-6572f0cb64bf7b5a.so: cannot open shared object file: No such file or directory

That .so file doesn't appear in the target directory.

/cc @eqrion who was seeing this also.

[gsollazzo]

I can replicate the problem on OSX on nightly [rustc 1.25.0-nightly (90eb44a 2018-01-29)].

[retep998]

This is a general issue with any crate that depends on internal rustc crates.

One way to solve this is with my ideal solution, which is to trash the whole dylib plugin infrastructure and instead have all the rustc internal libraries be normal rlibs with procedural macros being cdylibs (or separate binaries entirely with IPC).

[fschutt]

Is there any workaround yet?

EDIT: For people coming from google, run this:

export LD_LIBRARY_PATH=$(rustc --print sysroot)/lib:$LD_LIBRARY_PATH

see: rust-lang/rustfmt#1687 (comment)

[staktrace]

/cc @dtolnay - retep998's comment above makes it sound like cbindgen somehow depends on an internal rustc crate. The error message refers to libproc-macro, which I assume is pulled in via proc-macro2 in the syn and quote dependency lists. However reading the proc-macro2 documentation, it sounds like using proc-macro2 without the nightly feature should use it in a standalone mode that doesn't require internal rustc crates. Is my understanding correct? I'm just trying to figure out if there's a way to break this dependency so that we can publish a new version of cbindgen that is usable without LD_LIBRARY_PATH hacking.

[staktrace]

If #48217 gets merged then fixing this should be as easy as setting rpath=true in the Cargo.toml of the app (e.g. cbindgen in this case).

[retep998]

It would only "fix" it on platforms that have rpath. Windows users would be left out in the cold.

[steveklabnik]

Triage: the sysroot system hasn't changed at all.

[mati865]

It works fine on Linux nightly.

Steps for verification:

1. git clone https://github.com/eqrion/cbindgen/
2. cd cbindgen
3. git checkout 270491f
4. cargo +nightly build --release
5. target/release/cbindgen

[bjorn3]

There are three options here: Setting LD_LIBRARY_PATH, using rustup run (which sets LD_LIBRARY_PATH internally) or compiling with -Crpath (doesn't work on Windows and doesn't allow moving the final executable or the rust toolchain)

[bjorn3]

The proc_macro crate is now only available as rlib and not as dylib. The only time this issue can show up now is if you link against the unstable rustc_driver crate or if you use -Cprefer-dynamic (eg because you have a dylib as cargo dependency). In both cases there is nothing we can do against this, but you actively chose to use dynamic linking rather than having rustc implicitly dynamically link things. As such I'm going to close this issue.