When using Askama at revision 36cbfd4bad8c3f534c8cb13f9ddbc463e1c44ef5, binaries produced by Rust nightly-2018-04-07 dynamically link libstd and libproc_macro which cannot be found

[ctsrc]

I originally misattributed this issue first as cross-rs/cross#193 and then as #72 but I have now found conclusively that simply using Askama at revision 36cbfd4 with Rust nightly-2018-04-07 causes the following problem: The produced binary gets dynamically linked to libstd and libproc_macro which cannot be found, resulting in it being possible to run the binary with cargo run but not by direct execution of ./target/debug/hello_askama (hello_askama is what I named the minimal example that is made based on the Askama README) as in rust-lang/cargo#4651.

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/hello_askama`
Hello, world!

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

$ ldd target/debug/hello_askama
	linux-vdso.so.1 =>  (0x00007fff265d1000)
	libproc_macro-d3bd4d284648dcab.so => not found
	libstd-b70fe684839d0aca.so => not found
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3db94ba000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3db92a3000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3db8ec3000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3db9921000)

I used a Cargo.toml that looks like this:

[package]

name = "hello_askama"
version = "0.0.1"
authors = [ "Your name <you@example.com>" ]

[dependencies]
askama = { git = "https://github.com/djc/askama", rev = "36cbfd4bad8c3f534c8cb13f9ddbc463e1c44ef5" }

[build-dependencies]
askama = { git = "https://github.com/djc/askama", rev = "36cbfd4bad8c3f534c8cb13f9ddbc463e1c44ef5" }

build.rs like in Askama README:

extern crate askama;

fn main() {
    askama::rerun_if_templates_changed();
}

templates/hello.htm like in Askama README:

Hello, {{ name }}!

src/main.rs like in Askama README:

#[macro_use]
extern crate askama;

use askama::Template;

#[derive(Template)]
#[template(path = "hello.htm")]
struct HelloTemplate<'a> {
    name: &'a str,
}

fn main() {
    let hello = HelloTemplate { name: "world" };
    println!("{}", hello.render().unwrap());
}

And like I said, I was using Rust nightly-2018-04-07.

rustup default nightly-2018-04-07

[ctsrc]

I did a git bisect.

mkdir -p ~/tmp
git clone git@github.com:djc/askama.git ~/tmp/askama-dyn-link-bisect
cd ~/tmp/askama-dyn-link-bisect/

cat > bisection_judge.sh <<EOF
#!/usr/bin/env sh

cargo clean
rm Cargo.lock

( cd testing && cargo build --test hello )

find target/debug/ -regextype posix-extended -regex 'target/debug/hello-[0-9a-f]+' | xargs -I{} sh -c {}
EOF

chmod 755 bisection_judge.sh

git bisect start
git bisect good 0.5.0
git bisect bad 36cbfd4
git bisect run ./bisection_judge.sh

The result is:

b787bb4aee6c2cad0c66ded874d5f37b8e4b0413 is the first bad commit
commit b787bb4aee6c2cad0c66ded874d5f37b8e4b0413
Author: Dirkjan Ochtman <dirkjan@ochtman.nl>
Date:   Mon Jan 8 23:54:35 2018 +0100

    Upgrade to syn-0.12 and quote-0.4

:040000 040000 926bbd7096b4aa8beb846eac2448262e00d5d3f0 89cd502732747a4a130532bedec767f2977b20c8 M	askama_derive
:040000 040000 76a43078e2f457cc0191cb12b02983f472abacbf 342e5cd8c31276bcbc4f1f10db4901da76aff59b M	askama_shared
bisect run success

[ctsrc]

I then manually checked that this result was correct because my bisection test was a bit simplified.

git checkout b787bb4aee6c2cad0c66ded874d5f37b8e4b0413
./bisection_judge.sh

[...]
target/debug/hello-b641949e8979cb5b: error while loading shared libraries: libtest-36a2b2eb166afc56.so: cannot open shared object file: No such file or directory

ldd target/debug/hello-b641949e8979cb5b

	linux-vdso.so.1 =>  (0x00007ffc5a790000)
	libtest-36a2b2eb166afc56.so => not found
	libproc_macro-d3bd4d284648dcab.so => not found
	libstd-b70fe684839d0aca.so => not found
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fd30ed8d000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd30eb6e000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd30e957000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd30e577000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fd30f1e7000)

Yes, the identified commit has the issue with dynamic linking of libstd and libproc_macro (as well as additionally libtest but that does not affect the validity of the result).

So something in b787bb4 makes it so that this issue occurs.

[djc]

Hey, sorry you're having so much trouble! When is the last time you've run cargo clean? This seems like the kind of thing that might be helped by cleaning out and starting over.

Otherwise, you should probably report this in the syn issue tracker, as this issue doesn't appear to have anything to do with Askama in particular. Please cc me so I can support the investigation and keep track of any changes we have to make here.

[ctsrc]

I've run cargo clean both for the most recent revision and as part of the bisect for each step above.

[ctsrc]

I will write a bug report for syn then :)

[ctsrc]

Until the issue in syn has been found and fixed I think this issue should be kept open since it affects Askama even though it is not within Askama itself, don't you agree?

[djc]

Yup, I explicitly left it open!

[dtolnay]

I opened #77 with a fix.

[ctsrc]

Thank you both :)