Repository navigation
MSVC-like targets ignore target spec's linker field #48506
Description
Normally if -C linker is not specified, the target spec is consulted. However, is is_like_msvc is set, rustc uses "link.exe" unconditionally. This seems like an oversight. For example, it prevents setting up link.exe-flavored LLD in a target spec (which works fine with -C linker, at least as far as invoking the right executable goes).
cc @retep998
Activity
hanna-kruppe commentedon Feb 24, 2018
Correction: Since it looks only at
is_like_msvc, not atlinker_flavor, it's still possible to use link.exe-flavored LLD by just not setting the former. Still seems odd to hard code that name and yet let-C linkeroverride it.retep998 commentedon Feb 24, 2018
Unlike all other targets, for the msvc targets rustc ends up going through some very complex logic to figure out where
link.exeis, as well as library paths. At the time LLD was not a viable option and there were never any msvc linkers other thanlink.exe, so it was easier to hardcodelink.exeinto all the complex search logic, instead of plumbing through the target spec configuration.If we do choose to respect the target spec in this case, then there are some unresolved questions. For example, should we still do all that complex search logic? It's extremely unlikely LLD will be found the same way as
link.exe. If we do end up just blindly shelling out to the linker when it isn'tlink.exe, do we still want to find the Windows SDK library paths ourselves? Currently for-C linkerwe don't do any special logic and just expect the user to go through all the hard work of ensuring the linker is inPATHand all the library paths are configured correctly.hanna-kruppe commentedon Feb 24, 2018
I think it's reasonable for
target.options.linkerto behave exactly like-C linker.alexcrichton commentedon Mar 6, 2018
This was fixed in #48125