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.
I can replicate the problem on OSX on nightly [rustc 1.25.0-nightly (90eb44a58 2018-01-29)].
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).
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: https://github.com/rust-lang-nursery/rustfmt/issues/1687#issuecomment-308756211
/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.
If rust-lang/rust#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).
It would only "fix" it on platforms that have rpath. Windows users would be left out in the cold.
Triage: the sysroot system hasn't changed at all.
It works fine on Linux nightly.
Steps for verification:
git clone https://github.com/eqrion/cbindgen/cd cbindgengit checkout 270491fcargo +nightly build --releasetarget/release/cbindgen
Most helpful comment
Is there any workaround yet?
EDIT: For people coming from google, run this:
see: https://github.com/rust-lang-nursery/rustfmt/issues/1687#issuecomment-308756211