Undefined symbols for x86_64 when using resolver="2"

[XAMPPRocky]

Problem
I was running into a strange dependency management issue that seemed like it might be solved with the resolver, however when I tried it out, it causes the linker to spit out a huge Undefined symbols for x86_64 error for symbols from core . I assume it's a bug in resolver="2" because it compiles when that isn't set.

Steps

1. Clone https://github.com/EmbarkStudios/rust-gpu
2. Checkout resolver-error
3. cargo build

Notes

Output of cargo version: cargo 1.52.0-nightly (c68432f1e 2021-03-02)

Error Message

(Gist because it exceed's GitHub's character limit for issues)

[ehuss]

One issue is that it looks like it is building the dylib multiple times. Cargo is issuing a warning about this:

warning: output filename collision.
The lib target `rustc_codegen_spirv` in package `rustc_codegen_spirv v0.4.0-alpha.0 (/Users/eric/Proj/rust/cargo/scratch/rust-gpu/crates/rustc_codegen_spirv)` has the same output filename as the lib target `rustc_codegen_spirv` in package `rustc_codegen_spirv v0.4.0-alpha.0 (/Users/eric/Proj/rust/cargo/scratch/rust-gpu/crates/rustc_codegen_spirv)`.
Colliding filename is: /Users/eric/Proj/rust/cargo/scratch/rust-gpu/target/debug/deps/librustc_codegen_spirv.dylib
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The lib target `rustc_codegen_spirv` in package `rustc_codegen_spirv v0.4.0-alpha.0 (/Users/eric/Proj/rust/cargo/scratch/rust-gpu/crates/rustc_codegen_spirv)` has the same output filename as the lib target `rustc_codegen_spirv` in package `rustc_codegen_spirv v0.4.0-alpha.0 (/Users/eric/Proj/rust/cargo/scratch/rust-gpu/crates/rustc_codegen_spirv)`.
Colliding filename is: /Users/eric/Proj/rust/cargo/scratch/rust-gpu/target/debug/librustc_codegen_spirv.dylib
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The lib target `rustc_codegen_spirv` in package `rustc_codegen_spirv v0.4.0-alpha.0 (/Users/eric/Proj/rust/cargo/scratch/rust-gpu/crates/rustc_codegen_spirv)` has the same output filename as the lib target `rustc_codegen_spirv` in package `rustc_codegen_spirv v0.4.0-alpha.0 (/Users/eric/Proj/rust/cargo/scratch/rust-gpu/crates/rustc_codegen_spirv)`.
Colliding filename is: /Users/eric/Proj/rust/cargo/scratch/rust-gpu/target/debug/deps/librustc_codegen_spirv.dylib.dSYM
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.
warning: output filename collision.
The lib target `rustc_codegen_spirv` in package `rustc_codegen_spirv v0.4.0-alpha.0 (/Users/eric/Proj/rust/cargo/scratch/rust-gpu/crates/rustc_codegen_spirv)` has the same output filename as the lib target `rustc_codegen_spirv` in package `rustc_codegen_spirv v0.4.0-alpha.0 (/Users/eric/Proj/rust/cargo/scratch/rust-gpu/crates/rustc_codegen_spirv)`.
Colliding filename is: /Users/eric/Proj/rust/cargo/scratch/rust-gpu/target/debug/librustc_codegen_spirv.dylib.dSYM
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.

You can run cargo tree -i rustc_codegen_spirv -e features to get an explanation why it is being built multiple times.

Alternatively, you can run with the --target flag to ensure that build-scripts aren't shared.

I was able to successfully build that branch using --target and the latest nightly (nightly-2021-03-17) on both apple and linux. Can you try that?

Also, there are some known issues with dylib linking (for example, see rust-lang/rust#82151). In general, dylibs are poorly supported, so using them may have a rough experience.

[eddyb]

In general, dylibs are poorly supported, so using them may have a rough experience.

Yeah, sadly this is the only main legitimate usecase for dylib (a rustc plugin), though long-term we may be able to build a custom driver, like clippy and miri have (or "just" upstream the backend, though that has other tricky implications).

[ehuss]

I'm going to close this as a duplicate of #6313 which is tracking the general problem of duplicate artifact naming. Unfortunately dylibs are particularly difficult to handle since they are sensitive to the path and filename, which generally can't contain cargo hashes. Cargo definitely needs to do better here, especially with the error messages.

As for the greater issue of having a story for supporting dylibs, I think that's a little bigger than what can be dealt with in a cargo issue.

[XAMPPRocky]

As for the greater issue of having a story for supporting dylibs, I think that's a little bigger than what can be dealt with in a cargo issue.

I'm not sure I agree with this being a dylib issue so much as it is a resolver="2" issue. The project builds, compiles, and links successfully with resolver="1", it's only when resolver="2" is added do these linker errors appear.