Compiling from msbuild incorrectly uses target build tools for build scripts

[dlon]

The problem arises when running cargo build from within a VS project and targeting something other than the native arch (e.g., using msbuild.exe myproj.sln /p:Platform=otherarch). When cargo builds a build script, it uses the target linker (added to PATH by Visual Studio) instead of the host linker, which naturally fails.

This is a problem as of Rust 1.83 due to the following fix: #1201. That PR also contains some discussion about this issue.

[dlon]

@NobodyXu @ChrisDenton Would you accept a PR based on your suggestion of parsing the output of cl.exe? :)

The odd thing about it is that the msbuild tools will be used for the native target build scripts, but not otherwise. That's a bit counter-intuitive, perhaps.

[NobodyXu]

Yes I'm willing to review and merge it

[NobodyXu]

The odd thing about it is that the msbuild tools will be used for the native target build scripts, but not otherwise. That's a bit counter-intuitive, perhaps.

Well cc doesn't link anything, only compile and then archive.

[ChrisDenton]

Looking at the code, for Visual Studio proper (e.g. after vcvars.bat) we use VSCMD_ARG_TGT_ARCH to verify the environment is set up for the target and then VSINSTALLDIR to find the path to Visual Studio, which we then use to set the toolchain to the right target:

cc-rs/src/windows/find_tools.rs

Lines 390 to 393 in 5daf14e

	if is_vscmd_target(target, env_getter) == Some(false) {
	// We will only get here with versions 15+.
	let vs_install_dir: PathBuf = env_getter.get_env("VSINSTALLDIR")?.into();
	tool_from_vs15plus_instance(tool, target, &vs_install_dir, env_getter)

cc-rs/src/windows/find_tools.rs

Lines 358 to 370 in 5daf14e

	fn is_vscmd_target(target: TargetArch<'_>, env_getter: &dyn EnvGetter) -> Option<bool> {
	let vscmd_arch = env_getter.get_env("VSCMD_ARG_TGT_ARCH")?;
	// Convert the Rust target arch to its VS arch equivalent.
	let arch = match target.into() {
	"x86_64" => "x64",
	"aarch64" | "arm64ec" => "arm64",
	"i686" | "i586" => "x86",
	"thumbv7a" => "arm",
	// An unrecognized arch.
	_ => return Some(false),
	};
	Some(vscmd_arch.as_ref() == arch)
	}

MSBuild does not set either of those nor does it set anything equivalent. For VSCMD_ARG_TGT_ARCH we can instead parse the header of cl.exe. For VSINSTALLDIR I guess in the case where there's a target mismatch we can instead just return None from find_msvc_environment so that it'll fallback to finding the latest matching tools.

[NobodyXu]

For VSCMD_ARG_TGT_ARCH we can instead parse the header of cl.exe.

Hmmm how hard would it be?
Would it be portable?

For VSINSTALLDIR I guess in the case where there's a target mismatch we can instead just return None from find_msvc_environment so that it'll fallback to finding the latest matching tools.

👍

[ChrisDenton]

Hmmm how hard would it be?

I meant the thing I mentioned earlier about parsing the line that appears at the top of stderr from cl.exe (which cl.exe actually calls the "logo").

[NobodyXu]

Thanks for clarification that's pretty portable and quite reliable way of doing it, I don't think we have a better way to do it

[dlon]

I've now opened #1310 to fix this issue. Thank you both for the help!