rustc fails to compile when -L /usr/local/lib (on Linux, at least)

[rrichardson]

rust-bindgen sets cargo:rustc -L to /usr/local/lib via build.rs

When this happens, linking fails because duplicate candidate dylibs are found in the bootstrap libs: (/usr/local/lib) and the rustlib (/usr/local/lib/rustlib/../lib)

Specific errors below:

[rrichardson]

src/lib.rs:1:1: 1:1 error: multiple dylib candidates for `std` found
src/lib.rs:1 #![crate_name = "bindgen"]
 ^
src/lib.rs:1:1: 1:1 note: candidate #1: /usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-4e7c5e5c.so
src/lib.rs:1 #![crate_name = "bindgen"]
 ^
src/lib.rs:1:1: 1:1 note: candidate #2: /usr/local/lib/libstd-4e7c5e5c.so
src/lib.rs:1 #![crate_name = "bindgen"]
 ^
src/lib.rs:8:24: 8:41 error: multiple dylib candidates for `log` found
src/lib.rs:8 #[phase(plugin, link)] extern crate log;
 ^~~~~~~~~~~~~~~~~
src/lib.rs:8:24: 8:41 note: candidate #1: /usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblog-4e7c5e5c.so
src/lib.rs:8 #[phase(plugin, link)] extern crate log;
 ^~~~~~~~~~~~~~~~~
src/lib.rs:8:24: 8:41 note: candidate #2: /usr/local/lib/liblog-4e7c5e5c.so
src/lib.rs:8 #[phase(plugin, link)] extern crate log;
 ^~~~~~~~~~~~~~~~~
src/lib.rs:8:24: 8:41 error: multiple dylib candidates for `regex` found
src/lib.rs:8 #[phase(plugin, link)] extern crate log;
 ^~~~~~~~~~~~~~~~~
src/lib.rs:8:24: 8:41 note: candidate #1: /usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libregex-4e7c5e5c.so
src/lib.rs:8 #[phase(plugin, link)] extern crate log;
 ^~~~~~~~~~~~~~~~~
src/lib.rs:8:24: 8:41 note: candidate #2: /usr/local/lib/libregex-4e7c5e5c.so
src/lib.rs:8 #[phase(plugin, link)] extern crate log;

[brson]

I believe the correct way to solve this is to remove the duplication entirely, but the correct way to do that is to restructure the bootstrap (#11145), which is a sizable effort.

In the short term we might hack around this by blacklisting in the crate resolver the duplicate crates.

[brson]

I marked this 'easy' because the hack is not too difficult to implement. @alexcrichton what do you think of the hack?

[brson]

Another hack we might do is encode the stage number in the crate metadata and ignore crates from the wrong stage.

[alexcrichton]

I would prefer to take the route of #19941 before going through with blacklisting, I think that if cargo build scripts automatically add :native that this problem should largely just sort itself out.

[brson]

Another thing we might do is statically link all our executables, though we have some libs that are required to be dylibs.

[brson]

@alexcrichton Hm, agreed that this specific problem would be solved. It does seem to me a problem though that Rust libs can't live in the lib directory. I suspect that will bite us eventually, e.g. when distros start packaging crates themselves.

[alexcrichton]

True, in that case I'd probably prefer to encode some form of "compiler hash" into metadata. That way a compiler can reject all libraries built by other compilers (which is basically what we should do now anyway).

[codyps]

I've run into this same issue in meta-rust: https://github.com/jmesmon/meta-rust/issues/6 (and it's recently caused me issues again).

Causes build failures for me fairly often, as bitbake likes to rebuild things that are already installed sometimes.

As I mentioned in #19767, using prioritization of paths passed to the compiler (rather than searching all of them) is an easy fix for this.

Adding a "compiler hash" will not fix things for my case as I require builds to be reproducible (randomness is a problem) and in some cases will be rebuilding the same exact compiler.