MPI microsoft command line compile x86 conflict link error - c++

From the Developer Comand Prompt for VS 2013, I try to compile and link
a simple test MPI program.
Using the two batch files copied below, I type:
mpicc mpi
mpicl mpi
From the link step I get the following error message:
mpi.obj : fatal error LNK1112: module machine type 'X86' conflicts with target m
achine type 'x64'
I have been following the note on "How to compile and run a simple MS-MPI
program:" at:
http://blogs.technet.com/b/windowshpc/archive/2015/02/02/how-to-compile-and-run-a-simple-ms-mpi-program.aspx
I see the (x86) which seems to conflict with the fact that I am compiling
sixty-four bits but I don't know what else to specify as that is where
MPI install put the files in question.
Here is the mpicc.bat batch file
cl /I"c:\Program Files (x86)\Microsoft SDKs\MPI\Include" /I"C:\Program Files (x86)\Microsoft SDKs\MPI\Include\x64" /I /I"c:\program Files(x86)\Microsoft SDKs\windows\v8.1A\Include" /I"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\Include" /c %1.cpp
Here is the mpicl.bat batch file
link /machine:x64 /out:%1.exe /dynamicbase "msmpi.lib" /libpath:"c:\program Files (x86)\Microsoft SDKs\MPI\Lib\x64" /libpath:"c:\program files (x86)\Microsoft\Visual Studio 12.0\VC\LIB\amd64" /libpath:"c:\program files (x86)\Microsoft SDKs\Windows\v8.1A\x64" %1%.obj


I asked this question on askmpi#microsoft.com. They responded that I should
use a different command prompt in the Visual Studio Tools folder.
When I used the x64 Native Tools Command Prompt, the link step now works fine.

Related

Error while building C++ Protobuf using cmake [duplicate]

I just installed Windows 10 Creators Update (version 10.0.15063).
I have multiple versions of Visual Studio installed (2012, 2013, 2015 and 2017). I installed VS 2017 only a couple weeks ago.
Problem
CMake (version 3.8.1) no longer finds the C/C++ compiler when run inside a "VS2015 x64 Native Command Prompt" (it does work properly when run inside a VS 2017 command prompt).
Reproduction
Content of CMakeLists.txt:
project (test)
add_executable (test test.cpp)
(Content of test.cpp is irrelevant.)
CMake invocation, in a VS2015 x64 Native Command Prompt:
> mkdir build
> cd build
> cmake -G "Visual Studio 14 2015 Win64" ..
CMake output:
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:1 (project):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:1 (project):
No CMAKE_CXX_COMPILER could be found.
-- Configuring incomplete, errors occurred!
See also "D:/dev/cmaketest/build/CMakeFiles/CMakeOutput.log".
See also "D:/dev/cmaketest/build/CMakeFiles/CMakeError.log".
Analysis
The reason of the failure is clear when looking at CMakeFiles/CMakeError.log:
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\CL.exe /c /nologo /W0 /WX- /Od /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\\" /Fd"Debug\vc140.pdb" /Gd /TC /errorReport:queue CMakeCCompilerId.c
CMakeCCompilerId.c
Link:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe /ERRORREPORT:QUEUE /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:".\CompilerIdC.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdC.lib" /MACHINE:X64 Debug\CMakeCCompilerId.obj
LINK : fatal error LNK1158: cannot run 'rc.exe' [D:\dev\cmaketest\build\CMakeFiles\3.8.1\CompilerIdC\CompilerIdC.vcxproj]
rc.exe (Resource Compiler) is not found. Indeed, in the same VS 2015 command prompt:
> where rc.exe
INFO: Could not find files for the given pattern(s).
While it is found in a VS 2013 command prompt:
> where rc.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x64\rc.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x86\rc.exe
and a VS 2017 command prompt:
> where rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\rc.exe
Checking the content of the PATH environment variables in various VS command prompts:
Inside a VS 2013 command prompt, PATH contains
C:\Program Files (x86)\Windows Kits\8.1\bin\x64
Inside a VS 2017 command prompt, PATH contains
C:\Program Files (x86)\Windows Kits\10\bin\x64
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64
But inside a VS 2015 command prompt, PATH only contains
C:\Program Files (x86)\Windows Kits\10\bin\x64
which does not contain rc.exe.
Questions
Is this a known issue or is it specific to my system?
What could Windows 10 Creators Update possibly install, uninstall or alter in the system (perhaps something related to Windows SDKs) that would trigger this problem?
What is a clean way to resolve this?
Edit: Installed VS 2017 components:

Spent some time looking at this on three machines with Win10 Creators Edition and VS2010, VS2013, VS2015 and VS2017 installed, where it works on two machines and fails on the third. All had VS2015 Update 3 and all should have been installed with the same options.
Running the following batch file
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\vcvars64.bat
should setup the correct environment for VS2015 x64 environment. This should add
C:\Program Files (x86)\Windows Kits\10\bin\x64
to the PATH. This is where rc.exe should be. However on my failing machine rc.exe was missing from here, but it did exist in
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64
I went back and feeling like this was a setup issue I re-ran the VS2015 Update 3 setup and told it to add
Windows and Web Development -> Universal Windows App Development Tools -> Tools (1.4.1) and Windows 10 SDK (10.0.14393)
this caused rc.exe and related files to appear in
C:\Program Files (x86)\Windows Kits\10\bin\x64
Running rc -v on
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\rc.exe
and
C:\Program Files (x86)\Windows Kits\10\bin\x64\rc.exe
gave the same version number 10.0.10011.16384
Not sure why rc.exe was missing from the original install, but re-running the install and adding the other SDK fixed it for me. It looks like
C:\Program Files (x86)\Windows Kits\10\bin\x64\rc.exe
should be the default rc.exe but it was not setup by a previous install.

It's definitely not just you. I installed VS2017 yesterday and doing so seems to have produced the same problem on my end. I don't have a good solution (this should be reported to Microsoft as a bug) but I do have a hacky workaround.
I was able to copy rc.exe and rc.dll from
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64
to
C:\Program Files (x86)\Windows Kits\10\bin\x86
That resolved the issue for me. My hunch is that it's a registry key being overwritten but I haven't dug into it enough to be sure.

Met the same problem with Windows 10 15063.608 (Windows SDK 10.0.15063.0). The solution working for me is the hard links creation for Windows 10 kit binaries x64 and x86 folders like shown below (use the command prompt with admin rights):
mklink /J "C:\Program Files (x86)\Windows Kits\10\bin\x86" "C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86"
mklink /J "C:\Program Files (x86)\Windows Kits\10\bin\x64" "C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64"
(prior to running these commands just rename existing Windows Kits\10\bin\x64 and Windows Kits\10\bin\x86 folders - it looks like they are not in use.
P.S. mklink is a CMD command, not available under PowerShell

For whatever reason the built-in Tools (1.4.1) and Windows 10 SDK (10.0.14393) installer didn't work for me:
C:\Program Files (x86)\Windows Kits\10\bin\x86 got populated mid-install (success!)
...then de-populated (sorrow!)
And eventually the installer returned error -2147023293/0x80048646.
The "Windows 10 SDK (ver. 10.0.14393.795)" installer from the Windows SDK and emulator archive worked though: C:\Program Files (x86)\Windows Kits\10\bin\x86 gets and stays populated, including rc.exe.
Windows 7 x64, Visual Studio Professional 2015 Update 3.

Specifying CMAKE_SYSTEM_VERSION=8.1 solved the problem for me.

Similar problem with VS2017 Community 15.4.5 with Windows Sdk version 10.0.16299.0, but only for builds via TeamCity; builds from within VS work fine and so does building with MSBuild when starting from a VS developer command prompt. So this does not exactly answer the OP's question, but is so similar and this is one of the first search matches so I'll add it here.
Found a solution which does not require modifying the installation in any way (no linking/copying so less error-prone and easy to automate):
set the VisualStudioVersion environment variable to 15.0.
You could do this globally using the standard Windows gui for that (example for windows 10 here) but I'd rather strongly advise against it becaus it could interfere with other versions of VS, moreover it is not a change which is easily automated nor checked in into your build code and hence harder to reproduce omn different machines. A better alternative is to set this in the commandline where the build runs (cmd: set VisualStudioVersion=15.0 PS: $env:VisualStudioVersion = '15.0' in TeamCity: add env.VisualStudioVersion Parameter). Another alternative is to pass this directory to MSBuild as a property (pass /p:VisualStudioVersion=15.0 or in teamCity add system.VisualStudioVersion).

run your online installer vs_community2017.exe.
select modify your VS2017
select desktop development with C++
select Windows 10 SDK(my version is 10.0.10586) and install it
Run VS2015 command prompt:
> where rc
> C:\Program Files (x86)\Windows Kits\10\bin\x64\rc.exe
> C:\Program Files (x86)\Windows Kits\10\bin\x86\rc.exe
It seems that vs2017 default installs the newest SDK, and Overwrite old versions.

For anyone who gets stuck on this, one particular problem set is:
get a new windows 10 PC
install VS 2017 [*]
uninstall VS 2017 and
install VS 2015
If you do the above,
it seems that there is a bug or other behavior with the overall suite of Windows/VS installers.
There are basically it seems four problems MSFT have to fix (a) sometimes it just doesn't install rc.exe, (b) it doesn't install rc.exe if you "only" ask for the c++ stuff, you must ask for everything (c) the uninstall-install pipeline seems to be all messed up in various ways (d) even if it randomly installs rc.exe for you, it forgets or fouls-up the path.
:/
Long tedious story short, solutions seem to include one or more of
basically install or re-install 10.0.10011.16384 (but only that one, NOT the two later ones)
look around and see if rc.exe is plain, outright, not there. If so, install it (somewhere, anywhere)
in VS, you'd think you can install "just" the c++ stuff, but no. In practice you MUST check yes to all the web, blah blah development stuff. This seems to give you "more hope" of getting rc.exe. After doing this, revisit point 2, as you may well still not have it.
After doing 2 then 3 and likely 2 again, you likely STILL will not have it in your actual path. I would love to know which is the "best, natural" place to have it in your path, but that seems to be a lost cause. Just shove it in your path somewhere, anywhere.
Create a simple cmake file somewhere - and test it works.
. . . . . .
[*] it may well come with VS 2017, and don't forget VS 2017 may annoyingly get installed with something else, Unity etc.

Open "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\VsDevCmd.bat" in a text editor in administrator mode and change
the line
#if not "%WindowsSdkDir%" == "" #set PATH=%WindowsSdkDir%bin\x86;%PATH%
to
#if not "%WindowsSdkDir%" == "" #set PATH=%WindowsSdkDir%bin\x86;%WindowsSdkDir%bin\%WindowsSDKVersion%x86;%PATH%

I had the exact same problem. Multiple Visual studio versions, including 2015 and 2017.
My solution was to run the cmake command from 2017 developer command prompt, and specify the 2015 visual studio version with:
cmake -G "Visual Studio 14 2015" ..

Seems like when you install a newer version of Visual Studio the more recent SDK will be chosen by default.
You must select the SDK (8.1) that is installed with VS2015:
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" <arch> 8.1
I found the right answer here

execute following command on native 64/86 visual studio command prompt to set correct version For vs2015 --
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 8.1
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 8.1
execute following command on native 64/86 visual studio command promptto set correct version For vs2013 -
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" amd64 7.1
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86 7.1
This will set correct path and execute without any issue.
I have tested this on WIN10 with VS2013,VS2015,VS2017 installed.

After trying to install > py -3.11 -m pip zodb I got that pesky LNK1158 error.
I have VC files at:
Host Target Resource Compiler Version 10.0.10011.16384
x64 x64 "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\rc.exe"
x64 x64 "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\rcdll.dll"
x64 x86 "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86\rc.exe"
x64 x86 "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86\rcdll.dll"
Host Target Linker Version 14.00.24245.0
x64 x64 "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\link.exe"
x86 x86 "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe"
x64 x86 "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64_x86\link.exe"
x86 x64 "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\link.exe"
LINK need RC for cPersist from persistent-4.9.1.tar.gz
Setup.py run x86_amd64 tools for target Python 3.11.0rc2 64-bit
=> need to copy x64-x64 rc.exe and rcdll.dll to x86_amd64 directory
Because I'm lazy - fast XCOPY was enough and then new try:
PS > py -3.11 -m pip install zodb
... later ...
PS > # NO ERRORS - I AM HAPPY GUY NOW!

Unreal Engine 4 Building Error: Unknow platform for action trying to compile dte80a.cpp

Building UE4Editor and ShaderCompileWorker...
Using
Visual Studio 2019 14.28.29913 toolchain (C:\msvs\2019\Professional\VC\Tools\MSVC\14.28.29910)
and Windows 10.0.18362.0 SDK (C:\Program Files (x86)\Windows Kits\10).
Unknown platform for action: command 'C:\msvs\2019\Professional\VC\Tools\MSVC\14.28.29910\bin\HostX64\x64\cl.exe',
arguments
'"H:\ProjectA\Engine\Engine\Intermediate\Build\Win64\UE4Editor\Development\VisualStudioDTE\dte80a.cpp"
/c /nologo /Fo "H:\ProjectA\Engine\Engine\Intermediate\Build\Win64\UE4Editor\Development\VisualStudioDTE\dte80a.obj"
/I .
/I C:\msvs\2019\Professional\VC\Tools\MSVC\14.28.29910\INCLUDE
/I "C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um"
/I "C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt"
/I "C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared"
/I "C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um"
/I "C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\winrt"'
C:\msvs\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.MakeFile.Targets(45,5):
error MSB3073:
The command
"..\..\Build\BatchFiles\Build.bat
-Target="UE4Editor Win64 Development"
-Target="ShaderCompileWorker Win64 Development -Quiet" -WaitMutex -FromMsBuild"
exited with code 6.
An error occurred while building UE4 Engine (UE4Editor and ShaderCompileWorker) from source code.
I have tried clean and rebuild quite many times. Seems not helping.
How should I solve this problem?

Unknown platform for action: command is the key.
Find this string in your solution. You will find it in unrealBuildTool.
And set breakpoint at the line.
The issue maybe is the parseActionPlatform make mistake. And find out the reason.
Maybe is your action.commandPath.fullname contains condition is fail. Try to fix it.
Maybe this answer will be deleted again. But I don't care. Because I fix the same issue use these two solution.

rc.exe no longer found in VS 2015 Command Prompt

I just installed Windows 10 Creators Update (version 10.0.15063).
I have multiple versions of Visual Studio installed (2012, 2013, 2015 and 2017). I installed VS 2017 only a couple weeks ago.
Problem
CMake (version 3.8.1) no longer finds the C/C++ compiler when run inside a "VS2015 x64 Native Command Prompt" (it does work properly when run inside a VS 2017 command prompt).
Reproduction
Content of CMakeLists.txt:
project (test)
add_executable (test test.cpp)
(Content of test.cpp is irrelevant.)
CMake invocation, in a VS2015 x64 Native Command Prompt:
> mkdir build
> cd build
> cmake -G "Visual Studio 14 2015 Win64" ..
CMake output:
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:1 (project):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:1 (project):
No CMAKE_CXX_COMPILER could be found.
-- Configuring incomplete, errors occurred!
See also "D:/dev/cmaketest/build/CMakeFiles/CMakeOutput.log".
See also "D:/dev/cmaketest/build/CMakeFiles/CMakeError.log".
Analysis
The reason of the failure is clear when looking at CMakeFiles/CMakeError.log:
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\CL.exe /c /nologo /W0 /WX- /Od /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\\" /Fd"Debug\vc140.pdb" /Gd /TC /errorReport:queue CMakeCCompilerId.c
CMakeCCompilerId.c
Link:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe /ERRORREPORT:QUEUE /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:".\CompilerIdC.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdC.lib" /MACHINE:X64 Debug\CMakeCCompilerId.obj
LINK : fatal error LNK1158: cannot run 'rc.exe' [D:\dev\cmaketest\build\CMakeFiles\3.8.1\CompilerIdC\CompilerIdC.vcxproj]
rc.exe (Resource Compiler) is not found. Indeed, in the same VS 2015 command prompt:
> where rc.exe
INFO: Could not find files for the given pattern(s).
While it is found in a VS 2013 command prompt:
> where rc.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x64\rc.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x86\rc.exe
and a VS 2017 command prompt:
> where rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\rc.exe
Checking the content of the PATH environment variables in various VS command prompts:
Inside a VS 2013 command prompt, PATH contains
C:\Program Files (x86)\Windows Kits\8.1\bin\x64
Inside a VS 2017 command prompt, PATH contains
C:\Program Files (x86)\Windows Kits\10\bin\x64
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64
But inside a VS 2015 command prompt, PATH only contains
C:\Program Files (x86)\Windows Kits\10\bin\x64
which does not contain rc.exe.
Questions
Is this a known issue or is it specific to my system?
What could Windows 10 Creators Update possibly install, uninstall or alter in the system (perhaps something related to Windows SDKs) that would trigger this problem?
What is a clean way to resolve this?
Edit: Installed VS 2017 components:

Spent some time looking at this on three machines with Win10 Creators Edition and VS2010, VS2013, VS2015 and VS2017 installed, where it works on two machines and fails on the third. All had VS2015 Update 3 and all should have been installed with the same options.
Running the following batch file
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\vcvars64.bat
should setup the correct environment for VS2015 x64 environment. This should add
C:\Program Files (x86)\Windows Kits\10\bin\x64
to the PATH. This is where rc.exe should be. However on my failing machine rc.exe was missing from here, but it did exist in
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64
I went back and feeling like this was a setup issue I re-ran the VS2015 Update 3 setup and told it to add
Windows and Web Development -> Universal Windows App Development Tools -> Tools (1.4.1) and Windows 10 SDK (10.0.14393)
this caused rc.exe and related files to appear in
C:\Program Files (x86)\Windows Kits\10\bin\x64
Running rc -v on
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\rc.exe
and
C:\Program Files (x86)\Windows Kits\10\bin\x64\rc.exe
gave the same version number 10.0.10011.16384
Not sure why rc.exe was missing from the original install, but re-running the install and adding the other SDK fixed it for me. It looks like
C:\Program Files (x86)\Windows Kits\10\bin\x64\rc.exe
should be the default rc.exe but it was not setup by a previous install.

It's definitely not just you. I installed VS2017 yesterday and doing so seems to have produced the same problem on my end. I don't have a good solution (this should be reported to Microsoft as a bug) but I do have a hacky workaround.
I was able to copy rc.exe and rc.dll from
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64
to
C:\Program Files (x86)\Windows Kits\10\bin\x86
That resolved the issue for me. My hunch is that it's a registry key being overwritten but I haven't dug into it enough to be sure.

Met the same problem with Windows 10 15063.608 (Windows SDK 10.0.15063.0). The solution working for me is the hard links creation for Windows 10 kit binaries x64 and x86 folders like shown below (use the command prompt with admin rights):
mklink /J "C:\Program Files (x86)\Windows Kits\10\bin\x86" "C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86"
mklink /J "C:\Program Files (x86)\Windows Kits\10\bin\x64" "C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64"
(prior to running these commands just rename existing Windows Kits\10\bin\x64 and Windows Kits\10\bin\x86 folders - it looks like they are not in use.
P.S. mklink is a CMD command, not available under PowerShell

For whatever reason the built-in Tools (1.4.1) and Windows 10 SDK (10.0.14393) installer didn't work for me:
C:\Program Files (x86)\Windows Kits\10\bin\x86 got populated mid-install (success!)
...then de-populated (sorrow!)
And eventually the installer returned error -2147023293/0x80048646.
The "Windows 10 SDK (ver. 10.0.14393.795)" installer from the Windows SDK and emulator archive worked though: C:\Program Files (x86)\Windows Kits\10\bin\x86 gets and stays populated, including rc.exe.
Windows 7 x64, Visual Studio Professional 2015 Update 3.

Specifying CMAKE_SYSTEM_VERSION=8.1 solved the problem for me.

Similar problem with VS2017 Community 15.4.5 with Windows Sdk version 10.0.16299.0, but only for builds via TeamCity; builds from within VS work fine and so does building with MSBuild when starting from a VS developer command prompt. So this does not exactly answer the OP's question, but is so similar and this is one of the first search matches so I'll add it here.
Found a solution which does not require modifying the installation in any way (no linking/copying so less error-prone and easy to automate):
set the VisualStudioVersion environment variable to 15.0.
You could do this globally using the standard Windows gui for that (example for windows 10 here) but I'd rather strongly advise against it becaus it could interfere with other versions of VS, moreover it is not a change which is easily automated nor checked in into your build code and hence harder to reproduce omn different machines. A better alternative is to set this in the commandline where the build runs (cmd: set VisualStudioVersion=15.0 PS: $env:VisualStudioVersion = '15.0' in TeamCity: add env.VisualStudioVersion Parameter). Another alternative is to pass this directory to MSBuild as a property (pass /p:VisualStudioVersion=15.0 or in teamCity add system.VisualStudioVersion).

run your online installer vs_community2017.exe.
select modify your VS2017
select desktop development with C++
select Windows 10 SDK(my version is 10.0.10586) and install it
Run VS2015 command prompt:
> where rc
> C:\Program Files (x86)\Windows Kits\10\bin\x64\rc.exe
> C:\Program Files (x86)\Windows Kits\10\bin\x86\rc.exe
It seems that vs2017 default installs the newest SDK, and Overwrite old versions.

For anyone who gets stuck on this, one particular problem set is:
get a new windows 10 PC
install VS 2017 [*]
uninstall VS 2017 and
install VS 2015
If you do the above,
it seems that there is a bug or other behavior with the overall suite of Windows/VS installers.
There are basically it seems four problems MSFT have to fix (a) sometimes it just doesn't install rc.exe, (b) it doesn't install rc.exe if you "only" ask for the c++ stuff, you must ask for everything (c) the uninstall-install pipeline seems to be all messed up in various ways (d) even if it randomly installs rc.exe for you, it forgets or fouls-up the path.
:/
Long tedious story short, solutions seem to include one or more of
basically install or re-install 10.0.10011.16384 (but only that one, NOT the two later ones)
look around and see if rc.exe is plain, outright, not there. If so, install it (somewhere, anywhere)
in VS, you'd think you can install "just" the c++ stuff, but no. In practice you MUST check yes to all the web, blah blah development stuff. This seems to give you "more hope" of getting rc.exe. After doing this, revisit point 2, as you may well still not have it.
After doing 2 then 3 and likely 2 again, you likely STILL will not have it in your actual path. I would love to know which is the "best, natural" place to have it in your path, but that seems to be a lost cause. Just shove it in your path somewhere, anywhere.
Create a simple cmake file somewhere - and test it works.
. . . . . .
[*] it may well come with VS 2017, and don't forget VS 2017 may annoyingly get installed with something else, Unity etc.

Open "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\VsDevCmd.bat" in a text editor in administrator mode and change
the line
#if not "%WindowsSdkDir%" == "" #set PATH=%WindowsSdkDir%bin\x86;%PATH%
to
#if not "%WindowsSdkDir%" == "" #set PATH=%WindowsSdkDir%bin\x86;%WindowsSdkDir%bin\%WindowsSDKVersion%x86;%PATH%

I had the exact same problem. Multiple Visual studio versions, including 2015 and 2017.
My solution was to run the cmake command from 2017 developer command prompt, and specify the 2015 visual studio version with:
cmake -G "Visual Studio 14 2015" ..

Seems like when you install a newer version of Visual Studio the more recent SDK will be chosen by default.
You must select the SDK (8.1) that is installed with VS2015:
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" <arch> 8.1
I found the right answer here

execute following command on native 64/86 visual studio command prompt to set correct version For vs2015 --
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 8.1
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 8.1
execute following command on native 64/86 visual studio command promptto set correct version For vs2013 -
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" amd64 7.1
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86 7.1
This will set correct path and execute without any issue.
I have tested this on WIN10 with VS2013,VS2015,VS2017 installed.

After trying to install > py -3.11 -m pip zodb I got that pesky LNK1158 error.
I have VC files at:
Host Target Resource Compiler Version 10.0.10011.16384
x64 x64 "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\rc.exe"
x64 x64 "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\rcdll.dll"
x64 x86 "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86\rc.exe"
x64 x86 "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86\rcdll.dll"
Host Target Linker Version 14.00.24245.0
x64 x64 "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\link.exe"
x86 x86 "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe"
x64 x86 "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64_x86\link.exe"
x86 x64 "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\link.exe"
LINK need RC for cPersist from persistent-4.9.1.tar.gz
Setup.py run x86_amd64 tools for target Python 3.11.0rc2 64-bit
=> need to copy x64-x64 rc.exe and rcdll.dll to x86_amd64 directory
Because I'm lazy - fast XCOPY was enough and then new try:
PS > py -3.11 -m pip install zodb
... later ...
PS > # NO ERRORS - I AM HAPPY GUY NOW!

MSVC can't find its libs

For some purpose that is not really important I used MSVC 2012 in console mode (Windows 8x64) and when I tried to compile "Hello, World!" it didn't find its stabdard library and linker couldn't find some of its lib-files. So in the end I managed to configure both compile and link commands to make them work properly:
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\cl.exe" -c main.cpp /I
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include"
and for link:
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\link.exe"
main.obj
/LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib"
/LIBPATH:"C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86"
To sum up I want to know, how can they be configured so that cl found its headers and link found those libs. Please consider that I'm going to use them in Qt Creator, where they don't work and I've just found a way of getting them to work but from outside of Creator and I need to do it by Creators' means (nmake or jom options that is).

You need to call
call %ProgramFiles(x86)%\Microsoft Visual Studio 12.0\VC\vcvarsall.bat
in your command line window. This sets up a usable environment.

Error "fatal error C1034: windows.h: no include path set"

OS Windows Vista Ultimate
I am trying to run a program called minimal.c. When I type at the command line:
C:\Users\nathan\Desktop>cl minimal.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
minimal.c
minimal.c(5) : fatal error C1034: windows.h: no include path set
I have set all the paths:
C:\Users\nathan\Desktop>path
PATH=C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin;C:\Windows\system3
;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files (x86)\ATI Technologies\AT
.ACE\Core-Static;C:\Program Files\Intel\DMIX;c:\Program Files (x86)\Microsoft S
L Server\100\Tools\Binn\;c:\Program Files (x86)\Microsoft SQL Server\100\DTS\Bi
n\;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Program Files (x86)\Java\jdk1.
.0_13\bin;C:\Program Files (x86)\Autodesk\Backburner\;C:\Program Files (x86)\Co
mon Files\Autodesk Shared\;C:\Program Files (x86)\Microsoft DirectX SDK (March
009)\Include;C:\Users\nathan\Desktop\glut-3.7.6-bin\glut-3.7.6-bin;C:\Program F
les (x86)\Microsoft Visual Studio 8\Common7\IDE;C:\Program Files (x86)\Microsof
Visual Studio 8\VC\PlatformSDK\Include;C:\Program Files (x86)\Microsoft Visual
Studio 8\VC\PlatformSDK\Include\gl
I have gone and made sure windows.h is in the directory. I'm setting the path too. It's
in C:\Program Files (x86)\Microsoft Visual Studio 8\VC\PlatformSDK\Include.
I have Visual Studio 2005.
I have exhausted all possibilities. Any ideas?

You could also run the vcvars32.bat file from the directory C:\Program Files\Microsoft Visual Studio 8\VC\bin (this is in your path) prior to your cl command.
Like this:
C:\Users\nathan\Desktop>vcvars32
C:\Users\nathan\Desktop>cl minimal.c
vcvars32 calls C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat which sets up the required environment for compiling and linking.
The environment variables are INCLUDE, LIB, and PATH.
The compiler looks for header files in the INCLUDE path during compile, and libraries are fetched from the LIB path during link.

For me, with Visual Studio 2017,
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\vsdevcmd.bat"
is the command to use before compiling with cl.
Here is the documentation.

When you started the command line, did you run the included command line shortcut that comes with the Visual Studio setup? This will set the correct environment variables for you so that the compilation will work correctly.

In your project folder, open a PowerShell window and run:
cmd /c 'call "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Auxiliary\Build\vcvars64.bat" && cl minimal.c '

You've added your INCLUDE paths to your PATH environment variable. Use vcvars32.bat as the others have suggested.

Your path variable might be too long. Windows can’t take more than 1023 characters in the PATH environment variable.

I had the same issue getting the
fatal error C1034: stdio.h: no include path set
and after running the C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build>vcvars64.bat cmd/batch script would get the
fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory
error message. From here, and other posts on that page, I suspected that the Windows 10 SDK package must be installed. After installation and running the vcvars64.bat script from the path mentioned above, the problem was solved.
P.S. As explained here, an alternative to manually finding and running the above cmd/batch script, you may just do +Q and search for Developer Command Prompt for ..., in my case it is Developer Command Prompt for VS 2022.

if you have version 2017 of the compiler cl.exe (you installed Visual Studio 2017), in the command prompt you need go to "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Auxiliary\Build" and run 'vcvars32.bat' for x86 compilation or vcvars64.bat for x64 compilation.