Linking to external (C) libraries fails on nightly rust, when the stable Rust from Debian unstable is installed

[ntninja]

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).

[alexcrichton]

Thanks for the report! This is likely caused by some dependencies' build script not indicating that native= should be prepended on the search path for the system directory. Once you take care of that though it should be good to go!

[ntninja]

Thanks for the hint, I had never considered that this might be caused by a build script.

Specifically I found this line in codegens build.rs file:

println!("cargo:rustc-link-search={}", clang_dir.to_str().unwrap());

changing it to

println!("cargo:rustc-link-search=native={}", clang_dir.to_str().unwrap());

indeed fixes the problem.

[nox]

native={} instead of {} breaks finding libclang on OS X when running cargo run in rust-bindgen. Can anyone explain in a clear way what's the difference between the two? I couldn't find it documented anywhere.