Add an option to re-allow false positives in crate loading.

[ghost]

When trying to reinstall rust-sdl:

src/sdl_image/lib.rs:7:1: 7:32 error: multiple rlib candidates for `sdl` found
src/sdl_image/lib.rs:7 extern crate sdl = "sdl#0.3.2";
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/sdl_image/lib.rs:7:1: 7:32 note: candidate #1: /var/tmp/paludis/build/dev-rust-sdl-scm/work/sdl-scm/libsdl-e351513a-0.3.2.rlib
src/sdl_image/lib.rs:7 extern crate sdl = "sdl#0.3.2";
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/sdl_image/lib.rs:7:1: 7:32 note: candidate #2: /usr/lib64/libsdl-e351513a-0.3.2.rlib
src/sdl_image/lib.rs:7 extern crate sdl = "sdl#0.3.2";

Introduced by #13017, combined with #11802 this is a packaging showstopper. If a package and its dependency are installed to the same directory, there is no way to rebuild it without recursively uninstalling everything first.

Also, these are rlibs.

[alexcrichton]

The compiler doesn't understand that these are false positives, this is a legitimate error that the compiler is emitting. The compiler has no way of knowing whether those two files are exactly the same (short of comparing the contents).

Why do you think this is not a bug? Are those two files symlinks to one another?

[ghost]

So give me the option to tell the compiler which one to use or which one to ignore. The rest of the world is fine using the first one on the command line, but I can understand why that won't work for Rust after seeing the Makefiles.

If you actually think two third-party rlibs with the same hash and version are not equally valid, and it can break something to link to the "wrong one", that makes me question the point of having versions and hashes.

[alexcrichton]

In that case, I'm tempted to close this in favor of #13733. The way you tell the compiler which one to ignore is by controlling what the -L flags are. This sort of behavior often indicates that bugs are afoot.

The point of versions and hashes are two disambiguate two libraries with the same and version, but likely a different source (encoded in the crate ID).

It sounds like there's some build business going on which needs to sort out the -L directories, and when including the system directories it falls under the purview of #13733.

Can you explain your build setup in some more detail? I don't quite understand what you're doing or how things are set up, and that may help more in understanding what's going on here.

[ghost]

The problem was my wishful thinking in trying to treat Rust libraries like regular system libraries, and there may be some badness in the way Paludis expects builds to happen too. I am indeed way too generous with my -Ls.

In any case, this would be solved by #11802. I should not have opened this one. My apologies.

[alexcrichton]

No worries! Feel free to keep opening issues, we want rust to be easy to package!

[ghost]

To elaborate on the build system, in an ideal world there is an exheres (bash) library called rust.exlib that can build every Rust package ever written. Individual package descriptions can then just be as simple as

SCM_REPOSITORY="git://github.com/alexcrichton/rs-splay"
require scm-git
require rust

SUMMARY="A splay tree implementation written in Rust"
HOMEPAGE="https://github.com/alexcrichton/rs-splay"
LICENCES="MIT"
SLOT="0"
PLATFORMS="~amd64 ~x86"
BUGS_TO="jurily@gmail.com"

src_compile() {
    # relative path + crate_id
    rust_lib_compile lib.rs splay
}

src_test() {
    rust_test splay
}

src_install() {
    rust_lib_install splay
}

...except I now have next to no idea how to sanitize the build environment in a generic manner. Back to RTFM, I guess.