Do not rely on file extensions after path canonicalization.

[vadimcn]

Rustc does not recognize libraries which are symlinked to files having extension other than .rlib. The problem is that find_library_crate calls fs::canonicalize on found library paths, but then the resulting path is passed to get_metadata_section, which assumes it will end in ".rlib" if it's an rlib (from https://internals.rust-lang.org/t/is-library-path-canonicalization-worth-it/3206).

cc #29433

[rust-highfive]

r? @nrc

(rust_highfive has picked a reviewer for you, use r? to override)

[vadimcn]

Also, I'd like to nominate this fix for backporting into 1.8.

[GuillaumeGomez]

Could you add a comma at the end of this line please?

[alexcrichton]

This seems pretty similar to #32317 in scope, but perhaps somewhat different in terms of problem solved? Could you also be sure to add a test for this as well?

[vadimcn]

No, I think it's the same issue. Wasn't aware #32317 existed.

[alexcrichton]

I think that #32317 is arguably more general, but I somewhat prefer this tactic as it solves the problem at hand without changing the semantics that much

[alexcrichton]

cc @taralx

[vadimcn]

Added a test in case you want to go with this one.

[taralx]

This fixes the problem that I have specifically, although #32317 is probably also worth doing long-term (once I work out what's broken about Windows with it).

[alexcrichton]

@bors: r+ cc3b6f2

Ok, thanks @vadimcn! @taralx yeah I think we'll want to take both strategies, so I'll merge this for now while you're working on #32317, and we can merge once the Windows issue is tracked down.

[bors]

⌛ Testing commit cc3b6f2 with merge 525aa61...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-64-x-armhf, auto-linux-64-x-armsf, auto-linux-64-x-freebsd, auto-linux-64-x-netbsd, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild

[eddyb]

Nominating for backport on behalf of @taralx.

[nikomatsakis]

Discussed in @rust-lang/compiler meeting. Is this fixing a regression or just some longstanding bug?

[taralx]

This is technically a regression due to #12474. Before that, symlinks named *.rlib worked, regardless of the name of the thing they pointed to.

[alexcrichton]

@nikomatsakis I believe, (ias @taralx pointed out) that this is just fixing a longstanding bug

[nikomatsakis]

@alexcrichton

I believe that this is just fixing a longstanding bug

In that case, I believe (based on consensus from previous @rust-lang/compiler meeting) we would prefer not to backport.

[vadimcn]

@rust-lang/compiler: Can you please reconsider? This prevents Rust builds from working on our build cluster. I believe this is a pretty non-invasive change, and the beta cycle has just started....