Using target x86_64-pc-windows-gnu still tries to link in msvcrt

[doawoo]

I have had a lot of success targeting Linux and macOS machines with this.
However I'm running into a puzzling issue, it seems that Rust really wants to link msvcrt, even when the command I'm specifying is:

cargo zigbuild --target x86_64-pc-windows-gnu

It complains about not being able to locate the library.

  = note: error: unable to find dynamic system library 'msvcrt' using strategy 'paths_first'. searched paths:
            /Users/digit/git/Jsonrs/native/jsonrs/target/x86_64-pc-windows-gnu/debug/deps/msvcrt.dll
            /Users/digit/git/Jsonrs/native/jsonrs/target/x86_64-pc-windows-gnu/debug/deps/msvcrt.lib
            /Users/digit/git/Jsonrs/native/jsonrs/target/x86_64-pc-windows-gnu/debug/deps/libmsvcrt.a
            /Users/digit/git/Jsonrs/native/jsonrs/target/debug/deps/msvcrt.dll
            /Users/digit/git/Jsonrs/native/jsonrs/target/debug/deps/msvcrt.lib
            /Users/digit/git/Jsonrs/native/jsonrs/target/debug/deps/libmsvcrt.a
            /Users/digit/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/x86_64-pc-windows-gnu/lib/msvcrt.dll
            /Users/digit/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/x86_64-pc-windows-gnu/lib/msvcrt.lib
            /Users/digit/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/x86_64-pc-windows-gnu/lib/libmsvcrt.a
            /Users/digit/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/x86_64-pc-windows-gnu/lib/msvcrt.dll
            /Users/digit/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/x86_64-pc-windows-gnu/lib/msvcrt.lib
            /Users/digit/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/x86_64-pc-windows-gnu/lib/libmsvcrt.a

Does this flag need to be filtered out in the linker argument processing step?
Re-running the long command that's spat out, and then removing the -lmsvcrt results in the build proceeding further until it hits the temp files that no longer exist post-build.

[messense]

Can you try filter out it in here?

cargo-zigbuild/src/zig.rs

Lines 105 to 132 in d420792

	if is_windows_gnu {
	#[allow(clippy::if_same_then_else)]
	if arg == "-lgcc_eh" {
	// zig doesn't provide gcc_eh alternative
	// We use libc++ to replace it on windows gnu targets
	return Some("-lc++".to_string());
	} else if arg == "-Wl,-Bdynamic"
	&& (zig_version.major, zig_version.minor) >= (0, 11)
	{
	// https://github.com/ziglang/zig/pull/16058
	// zig changes the linker behavior, -Bdynamic won't search *.a for mingw, but this may be fixed in the later version
	// here is a workaround to replace the linker switch with -search_paths_first, which will search for *.dll,*lib first,
	// then fallback to *.a
	return Some("-Wl,-search_paths_first".to_owned());
	} else if arg == "-lwindows" || arg == "-l:libpthread.a" || arg == "-lgcc" {
	return None;
	} else if arg == "-Wl,--disable-auto-image-base"
	|| arg == "-Wl,--dynamicbase"
	|| arg == "-Wl,--large-address-aware"
	|| (arg.starts_with("-Wl,")
	&& (arg.ends_with("/list.def") || arg.ends_with("\\list.def")))
	{
	// https://github.com/rust-lang/rust/blob/f0bc76ac41a0a832c9ee621e31aaf1f515d3d6a5/compiler/rustc_target/src/spec/windows_gnu_base.rs#L23
	// https://github.com/rust-lang/rust/blob/2fb0e8d162a021f8a795fb603f5d8c0017855160/compiler/rustc_target/src/spec/windows_gnu_base.rs#L22
	// https://github.com/rust-lang/rust/blob/f0bc76ac41a0a832c9ee621e31aaf1f515d3d6a5/compiler/rustc_target/src/spec/i686_pc_windows_gnu.rs#L16
	// zig doesn't support --disable-auto-image-base, --dynamicbase and --large-address-aware
	return None;
	}

Thanks

[messense]

FYI, -lmsvcrt seems to be added by Rust in https://github.com/rust-lang/rust/blob/b5723af3457b9cd3795eeb97e9af2d34964854f2/compiler/rustc_target/src/spec/base/windows_gnu.rs#L33-L44

[doawoo]

Thanks for the quick reply. Looking at the CI results there's some other gotchas involved here. I've cloned down your branch and will be playing a bit with it to see if I can resolve any of the linker issues I've seen in CI.

[TheButlah]

upgrading from version 0.18.4 to 0.19.3 seems to fix it for me. Just thought I'd let others know. It looks like it was fixed here: #274

PS. Thank you for making my life easier! I just sponsored on github.