Adding `wasm32-unknown-unknown` to a Rust toolchain compiled against a specific LLVM revision

[szilardszaloki]

@Kobzol Chromium builds its Rust toolchain against a specific LLVM revision. I'm adding the wasm32-unknown-unknown target to that toolchain, so I need rust-lld to be available. It was working correctly until this PR, but now the stage1 compiler no longer generates rust-lld. I'm uncertain whether just copying lld as rust-lld would work across all platforms — I suspect there may be compatibility issues. Curious about your thoughts.

[Kobzol]

Conceptually, it seems to me that if you're using "bring your own LLVM", where the LLVM isn't shipped in the sysroot and is provided externally, then it should also mean "bring your own LLD". How do you handle shipping the LLVM to the users of the Rust toolchain that you build? Could you handle shipping the LLD in the same way? I'm asking because when an external LLVM config is used, bootstrap doesn't attach LLVM to the rustc sysroot (but it did attach LLD to the sysroot before #139853).

Also, I'm still trying to find out how does wasm32-unknown-unknown figure out that it should use the self-contained LLD linker (rust-lld), rather than using a globally available LLD linker, as I don't see it in the target spec.

[szilardszaloki]

I can package lld the same way Chromium distributes its toolchain; I just wasn't certain whether copying lld as rust-lld would consistently work across all platforms — could you confirm?

[szilardszaloki]

As for how wasm32-unknown-unknown knows to use rust-lld:

rust/compiler/rustc_target/src/spec/base/wasm.rs

Lines 89 to 91 in efcbb94

	// we use the LLD shipped with the Rust toolchain by default
	linker: Some("rust-lld".into()),
	linker_flavor: LinkerFlavor::WasmLld(Cc::No),

[cuviper]

FWIW, in Fedora we've been directly patching those spec "rust-lld" lines to "lld" to use our external linker, but I'd love for that to be smarter. ISTR the work to switch to lld on host targets like x86_64-unknown-linux-gnu did have some logic for that? (or at least, it was planned...)

[Kobzol]

So, I can't really promise that your lld will work correctly in all cases as rust-lld would. However, before #139853, bootstrap (by accident) copied LLD from the external location (from llvm-config) into the sysroot and just renamed it as rust-lld. So if this was working for you before, then just renaming your lld as rust-lld should continue working.

[szilardszaloki]

@Kobzol Fair enough, thanks. Out of curiosity, are there any specific scenarios you think it might break in?

[Kobzol]

Not anything particular, no (I don't know in what situations is the logic of the LLD wrapper required).

[bjorn3]

The lld wrapper is only required when passing -fuse-ld=lld to gcc or clang as linker driver I believe as GCC will specifically look for ld.lld, and clang can't pass -flavor ld as first argument to tell lld which linker interface to use I think.

[szilardszaloki]

Thanks, guys — that's very helpful.