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.

[brson]

Still seems to be an issue. Adding -L prioritization would fix it. @alexcrichton does prioritizing -L make sense to you still?

[alexcrichton]

@brson could you elaborate on what you mean by prioritization? Do you mean that if we hit multiple candidates we just pick the first one?

[brson]

@alexchricton crates loaded from later -L directories win over crates loaded from earlier -L directories.

[codyps]

@brson I don't think that order (later-wins) solves things. I'd recommend searching in the order that the -L options are added instead (ie: earlier wins). This both matches with how ld works and allows us to keep using the target rust libs instead of accidentally linking in the host rust libs.

Of course, the complication with earlier-wins ordering is that it becomes less clear what the proper way to override things is. I haven't needed overriding in practice because I simply switch to using custom targets at that point, but it might be worth considering if there is a use case where earlier-wins doesn't completely resolve our issues.

[alexcrichton]

Hm it's certainly a possibility, yes. I've personally always found it to be a bug whenever this check trips and am generally glad it trips, but it has been annoying from time to time.

[brson]

This both matches with how ld works and allows us to keep using the target rust libs instead of accidentally linking in the host rust libs.

Thanks for the correction.

[steveklabnik]

Triage: has anyone seen this since 2016?

[jyn514]

Triage: this is working today:

$ rustc build.rs -L $(rustc --print sysroot)/lib
$ file build
build: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6deeda9153facaf71b74025e6759bbad4614ba4e, for GNU/Linux 3.2.0, with debug_info, not stripped

Looks like rustc_metadata now arbitrarily picks one of the two since they have the same crate hash:

 INFO rustc_metadata::creader resolving crate `std`
 INFO rustc_metadata::creader falling back to a load
 INFO rustc_metadata::locator lib candidate: /home/jnelson/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libstd-91db243dd05c003b.so
 INFO rustc_metadata::locator lib candidate: /home/jnelson/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-061c02acc74ada37.rlib
 INFO rustc_metadata::locator lib candidate: /home/jnelson/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-91db243dd05c003b.rlib
 INFO rustc_metadata::locator lib candidate: /home/jnelson/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-91db243dd05c003b.so
 INFO rustc_metadata::locator rlib reading metadata from: /home/jnelson/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-91db243dd05c003b.rlib
 INFO rustc_metadata::locator dylib reading metadata from: /home/jnelson/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/libstd-91db243dd05c003b.so
 INFO rustc_metadata::locator dylib reading metadata from: /home/jnelson/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-91db243dd05c003b.so
 INFO rustc_metadata::creader register crate `std` (cnum = 1. private_dep = false)