Running a binary built by cargo fails due to missing libraries; but `cargo run`ning 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.