[msvc] ucrt headers are not found under some circumstances

[glandium]

I'm not sure how useful this report is going to be, but I'm putting it out there, in case it helps.

I have a local crate that compiles some C++ code, that uses C-style header includes, e.g. #include <stddef.h> rather than #include <cstddef>. Compiling that code with the cc crate from a build.rs script failed, and verbose output showed the compiler not being able to find stddef.h. Manually setting the INCLUDE environment variable to contain the ucrt directory allowed to go past that, but I had other errors, so I tried to build with the same command line manually, which required even more directories in the INCLUDE environment variable. In the end, I got everything working with about 4 directories added to INCLUDE.

This is on Windows 10, with Visual Studio 2017 installed.

However, I don't know for sure what exact details are relevant, and I was about to try and figure that out (like, does it happen with #include <cstddef>? Was ucrt enough, or did the other directories matter too?) but I now can't reproduce the issue anymore. Now, what changed between when I did have the problem and now is that in between, I installed parts of the separate Windows SDK, which may have altered the SDK-related parts of the registry, and short of reinstalling Windows, there's no straightforward way I can go back to the previous setup.

[alexcrichton]

In general this crate attempts to find MSVC installations and automatically set the INCLUDE env var and others (same as how it finds cl.exe even though it's typically not in PATH). If that's not working though it may be a bug!

The probing all happens around here, and the best way to debug this is to probably add some println debugging there and try to figure out where the build script goes awry

[jrmuizel]

I ran into this and produced this solution https://github.com/alexcrichton/cc-rs/pull/425

[torokati44]

I'm also having the same issue, with no straightforward solution. See: https://github.com/ruffle-rs/ruffle/pull/3004#issuecomment-803212028 And also: https://github.com/torokati44/vp6-dec-rs/runs/2170888752?check_suite_focus=true#step:5:94

[torokati44]

After setting the VCINSTALLDIR environment variable, the compilation now succeeds, but the link.exe in use is that of GNU's coreutils (from MSYS2), and not that of MSVC... https://github.com/torokati44/vp6-dec-rs/commit/35ad658ae3bec1e10d16dec8c1b3debe5300f234 https://github.com/torokati44/vp6-dec-rs/runs/2171039400?check_suite_focus=true#step:5:20

[torokati44]

I believe I am supposed to source some vcvars batch file, and that would set %PATH% correctly, but as the build has to use a bash-like shell, I kinda have to emulate that batch file by hand...? Actually, I'd be fine with using lld-link instead (if it's installed on the GHA runners), but I could only find .compiler() on the Build builder, but not .linker().

[aminya]

I believe I am supposed to source some vcvars batch file, and that would set %PATH% correctly, but as the build has to use a bash-like shell, I kinda have to emulate that batch file by hand...? Actually, I'd be fine with using lld-link instead (if it's installed on the GHA runners), but I could only find .compiler() on the Build builder, but not .linker().

Is there a way to force using lld-link?

[aminya]

Adding this to .cargo/config.toml (in the project) forces using lld

[target.x86_64-pc-windows-msvc]
rustflags = ["-C", "linker=lld"]

You can use it for all the targets by the following, but it failed for me on linux.

[build]
rustflags = ["-C", "linker=lld"]

[Enyium]

I wrote the vcvars crate. You can get INCLUDE, WindowsLibPath and other environment variables out of it.