Programs using syn end up dynamically linking libproc_macro and libstd and not being able to run standalone when built with Rust nightly-2018-04-07

[ctsrc]

A library that I am trying to use is in turn using syn.

When I build my binary with Rust nightly-2018-04-07, the binary ends up being dynamically linked against libstd and libproc_macro, neither of which can be found.

Therefore it is only possible to execute with cargo run, and it is not possible to run the binary directly because attempting to do so results in error while loading shared libraries: libproc_macro-d3bd4d284648dcab.so: cannot open shared object file: No such file or directory.

I bisected the commits of the library I am using here: djc/askama#73

The dynamic linking of libstd and libproc_macro started happening after the version of syn used was changed from 0.11 to 0.12. Comparing the Cargo.toml of syn 0.11.11 to that of 0.12.0, it turns out that a dependency on proc-macro2 was introduced between these versions, and since https://github.com/alexcrichton/proc-macro2 is described as "a small shim over the proc_macro crate in the compiler intended to multiplex the current stable interface (as of 2017-07-05) and the upcoming richer interface", I guess this must be where the dynamic linking of libproc_macro comes from.

In your README there is a note about proc-macro2:

By default Syn uses the proc-macro2 crate to emulate the nightly compiler's procedural macro API in a stable way that works all the way back to Rust 1.15.0. This shim makes it possible to write code without regard for whether the current compiler version supports the features we use.

On a nightly compiler, to eliminate the stable shim and use the compiler's proc-macro directly, add proc-macro2 to your Cargo.toml and set its "nightly" feature which bypasses the stable shim.

[dependencies]
syn = "0.13"
proc-macro2 = { version = "0.3", features = ["nightly"] }

However, since the library that I am using on its own does not need nightly features, that library should do this of course.

And I think it would get messy if users of that library have to take into consideration something about a dependency of a dependency of a dependency.

Is there something that can be done in syn so that this problem can be resolved?

cc @djc (author of Askama, the library that I am using that has a dependency on syn.)

[ctsrc]

We can also observe the issue directly in the binaries produced for the syn examples by the way.

rustup default nightly-2018-04-07
git clone git@github.com:dtolnay/syn.git
cd syn
git checkout 98753ee
cd examples/dump-syntax
cargo build

ldd target/debug/dump-syntax

	linux-vdso.so.1 =>  (0x00007ffc126e2000)
	libproc_macro-d3bd4d284648dcab.so => not found
	libstd-b70fe684839d0aca.so => not found
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f241491f000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f241453f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f2414f3b000)

./target/debug/dump-syntax

./target/debug/dump-syntax: error while loading shared libraries: libproc_macro-d3bd4d284648dcab.so: cannot open shared object file: No such file or directory

[dtolnay]

There is a "proc-macro" feature that you can disable to eliminate the runtime dependency on libproc_macro. I pushed d111d6f to show how this works in the dump-syntax example.

[djc]

Can you explain why that is enabled by default? Not sure that makes sense to me.

[djc]

I looked into this a bit. I'm currently using the parse() function, which I think I have to when using the stable derive mechanism. However, that means I always have to have the runtime dependency on libproc_macro? Is it possible to have something that works on both stable and nightly?

[dtolnay]

It looks like you had a lot of proc macro code compiled into the askama crate. I opened djc/askama#77 to move all the proc macro code into your proc macro crate.