Linking to external (C) libraries fails on nightly rust, when the stable Rust from Debian unstable is installed #2478
Description
I tried to compile a development version of rust-bindgen, when it reported a build failure:
$ cargo install --verbose
Fresh libc v0.2.8
Fresh unicode-xid v0.0.3
Fresh rustc-serialize v0.3.18
Fresh winapi v0.2.5
Fresh bitflags v0.3.3
Fresh winapi-build v0.1.1
Fresh log v0.3.5
Fresh kernel32-sys v0.2.1
Fresh term v0.2.14
Fresh syntex_syntax v0.29.1
Compiling bindgen v0.16.0 (file:///home/alexander/src-ext/rust-bindgen)
Running `rustc src/lib.rs --crate-name bindgen --crate-type lib -C opt-level=3 --out-dir /home/alexander/src-ext/rust-bindgen/target/release --emit=dep-info,link -L dependency=/home/alexander/src-ext/rust-bindgen/target/release -L dependency=/home/alexander/src-ext/rust-bindgen/target/release/deps --extern libc=/home/alexander/src-ext/rust-bindgen/target/release/deps/liblibc-036fbedefddee9e8.rlib --extern syntex_syntax=/home/alexander/src-ext/rust-bindgen/target/release/deps/libsyntex_syntax-7f17e9c781e7d00e.rlib --extern log=/home/alexander/src-ext/rust-bindgen/target/release/deps/liblog-0ec442df0ecb416b.rlib -L /lib/x86_64-linux-gnu -l dylib=:libclang.so.1`
error: multiple matching crates for `std` [E0464]
note: candidates:
note: path: /home/alexander/.local/share/multirust/toolchains/nightly/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-18402db3.so
note: path: /home/alexander/.local/share/multirust/toolchains/nightly/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-18402db3.rlib
note: crate name: std
note: path: /usr/lib/x86_64-linux-gnu/libstd-35c36e89.so
note: crate name: std
error: can't find crate for `std` [E0463]
error: aborting due to 2 previous errors
failed to compile `bindgen v0.16.0 (file:///home/alexander/src-ext/rust-bindgen)`, intermediate artifacts can be found at `/home/alexander/src-ext/rust-bindgen/target`
Caused by:
Could not compile `bindgen`.
Caused by:
Process didn't exit successfully: `rustc src/lib.rs --crate-name bindgen --crate-type lib -C opt-level=3 --out-dir /home/alexander/src-ext/rust-bindgen/target/release --emit=dep-info,link -L dependency=/home/alexander/src-ext/rust-bindgen/target/release -L dependency=/home/alexander/src-ext/rust-bindgen/target/release/deps --extern libc=/home/alexander/src-ext/rust-bindgen/target/release/deps/liblibc-036fbedefddee9e8.rlib --extern syntex_syntax=/home/alexander/src-ext/rust-bindgen/target/release/deps/libsyntex_syntax-7f17e9c781e7d00e.rlib --extern log=/home/alexander/src-ext/rust-bindgen/target/release/deps/liblog-0ec442df0ecb416b.rlib -L /lib/x86_64-linux-gnu -l dylib=:libclang.so.1` (exit code: 101)
Running the failing command directly doesn't help, but (after taking a closer look at the error message) I realized that Rust doesn't know whether to use the std crate from it's own (nightly) installation (/home/alexander/.local/share/multirust/toolchains/nightly/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-18402db3.so), or the one globally installed on the system (/usr/lib/x86_64-linux-gnu/libstd-35c36e89.so). This is because cargo tells it to look for libraries in /lib/x86_64-linux-gnu (which in turn is a symlink to /usr/lib/x86_64-linux-gnu), so that it may find the required libclang.so.1.
This problem can be fixed by adding the native kind specifier to -L /lib/x86_64-linux-gnu (i.e.: -L native=/lib/x86_64-linux-gnu).