I have an older Windows 10 workstation with Rust 1.37 (stable-x86_64-pc-windows-msvc) and Visual Studio 2017 with the following features:
Visual C++ Build Tools core features
VC++ 2017 version 15.9 v14.16 latest v141 tools
Visual C++ 2017 Redistributable Update
Windows 10 SDK (10.0.17763.0)
Visual C++ tools for CMake
Testing tools core features - Build Tools
On this workstation, I can compile a program that runs fine on my target environment (Windows Server 2008 R2).
I have a newer Windows 10 workstation on which I installed the legacy version of Visual Studio 2017. Interestingly, the installer doesn't offer the exact same options for C++ build tools, but I think I have the necessary ones, e.g.:
VC++ 2017 version 15.9 v14.16 latest v141 tools
Visual C++ tools for CMake and Linux
Windows 10 SDK (10.0.17763.0)
However, when I compile the program (with the same Rust version/toolchain) on this computer, it errors out on my target environment with "The program can't start because VCRUNTIME140.dll is missing from your computer".
What am I missing here? How can I setup rustup/cargo to target my specific environment?
I think It’s because of not choosing some components when you install the vs.
by the way, vs 2015 is not a good choice.
So it turns out I was wrong: my project was not compiled with stable-x86_64-pc-windows-msvc on my older computer. I had at some point installed the x86_64-pc-windows-gnu toolchain and set it as the override for this project. Changing my toolchain to x86_64-pc-windows-gnu on the new computer produced a binary that was able to run on the target machine.
Rather than deleting this question, I'll leave it here for others who may need to target older Windows environments:
If you are having problems running a Rust binary on an older Windows computer, try compiling with x86_64-pc-windows-gnu rather than msvc.
Related
I'm very confused with "Microsoft SDK", "Platform toolset", "Windows kits". My computer always installs several versions of them and several build tools.
My questions are:
Why are there so many compilers? How do I use them correctly?
"%PATH_BUILDTOOL2022%\bin\Hostx86\x86\cl.exe"
"%PATH_BUILDTOOL2022%\bin\Hostx86\x64\cl.exe"
"%PATH_BUILDTOOL2022%\bin\Hostx64\x86\cl.exe"
"%PATH_BUILDTOOL2022%\bin\Hostx64\x64\cl.exe"
Where is platform toolset v143 in?
What are in "%ProgramFiles(x86)%\Microsoft SDKs", and what are "Microsft SDKs"?
What are in "%ProgramFiles(x86)%\Windows Kits" and what are "Windows Kits"?
What are in "%ProgramFiles(x86)%\Windows Kits\8.1"?
What are in "%ProgramFiles(x86)%\Windows Kits\10"?
It seems "%ProgramFiles(x86)%\Windows Kits\10" is on(depends on) "%ProgramFiles(x86)%\Windows Kits\8.1", isn't it? If yes, what's the relation between them?
What are.Net Framework SDKs? Where're they?
Know what are "Microsoft SDKs", "Windows Platform toolset" and "Windows Kits"
Not sure what you mean by "My computer always installs several versions of them", but my understanding is that:
In Visual C++, prior to compiling one selects information that targets the executable you are creating at a certain minimum Windows configuration (Windows version, Windows Build version and Platform Toolset, among others). The settings are found in Project, [Sol'n Name] Properties, General. Prior to compiling, one also selects the active configuration of the executable: x86 for 32-bit, x64 for 64-bit.
The Windows Version might be: 8, 10 or 11
The Windows Build Version is a flavor of the Windows version. By right clicking "ThisPC" and then Properties, one might see that they are running OS build version 19045.2486 of Windows 10.
The Platform Toolset refers to the version of Visual Studio one is using: v143 for VS 2022, v142 for VS 2019, v141 for VS 2017, v140 for VS 2015. FYI, one can install multiple (older) Platform Toolsets in an instance of Visual Studio
So if one targets their application to Windows 10 SDK 10.0.19041.0, the app may not run properly on a machine that has OS build version 17xxx installed.
To your specific questions:
There's a (cross-)compiler for every combination of target architecture and architecture that the compiler is running on.
Platform Toolset refers to the version of Visual Studio one is using as noted above. Each one of these requires that a version of the Microsoft Visual C++ Redistributable (see https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170) is installed on the target machine.
The Windows Kits refer to the Windows SDK one is targeting. You can elect which Windows SDK's you install with Visual Studio by opening Visual Studio Installer, selecting the Individual Components tab and scrolling to the bottom.
Microsoft SDK's are a broad range of Software Development Kits that enable technologies like: Silverlight, NuGetPackages, WindowsPhone, etc...
I've a Windows Server 2012 for make my build every night. I want to use CMake to generate Makefiles with NMake. But I don't want to install a complete Visual Studio just to get the tools (compiler / linker).
I want to know if there is a way to do that or if I have to install visual imperative ?
I search on web but the answers i found are not so clear...
Thanks
The commmand line build Tools has been removed from the Windows SDK as of the "Windows SDK for Windows 8" release. Earlier SDKs included compilers. So if you use an SDK prior to the Windows 8 era you can go with the older SDKs.
If you new the current SDK version you need to install developer Tools like Visual Studio.
Is there anyway to install or have VC++ Debug Runtime Distributable without installing Visual Studio ?
Just to run a dll that has been compiled in debug mode using VS2013 on another machine that hasn't VS2013.
For testing purposes, you can include the Debug DLLs you need 'side-by-side' with your application. You can find them on a machine with VS 2013 installed:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\redist\Debug_NonRedist
When you deploy your app, you must use Release mode distributions. For Win32 desktop apps, use these instructions. For Windows Store apps, you don't have to deploy the CRT as it's handled by the Windows Store.
OP was asking about 2013, but the title is general, so..
I just wanted to point out that in newer Visual Studio releases with the "select what you want" installer, for the debug runtime you need just "tools" or "build tools" (e.g. VC++ 2017 version 15.9 v14.16 latest v141 tools or MSVC v142 - VS 2019 C++ Build Tools, not to be confused with the toolset)
As for where you can find the libs, VS 2015 still has them basically in the same path outlined in Chuck's answer. From 2017, you should have something like:
<root>\Microsoft Visual Studio\2017\Community\VC\Redist\MSVC\14.16.27012\debug_nonredist
I'm running into problems generating a Visual Studio 2010 Express 64 bit project through CMake. I installed VS2010 Express first, then the Windows SDK 7.1 in order to be able to build 64 bit apps and then tried to compile my CMake project.
I do not remember this to be that difficult with 2008 Express, but with 2010 I fail again and again. 2010 searches per default for 7.0a SDK which is shipped with it. The express version seems to ship a reduced 32 bit version, which is located under
.../Program Files(X86)/Microsoft SDKs/Windows/7.0a
Windows SDK 7.1 64bit will be installed per default under
.../Program Files/Microsoft SDKs/Windows/7.0
In VS 2010 Express the platform SDK can be changed on a per-project-map basis and if I do so the inherited path macros surprisingly point to the correct SDK. The problem now is, that CMake is not happy about me screwing around in the project files by myself. Thus, it always resets the Platform SDK entry to the default value, which will make the Windows SDK point to 7.0a and result in complaints about missing 64 bit libs.
I now see two possibilities to resolve this:
Find a way to really integrate the 7.1 SDK into VS2010 Express, just like with VS2008. VS2008 searches the registry for the tag 'CurrentInstallFolder' in the Windows SDKs entry, and you can change this entry to point to another SDK.
Find a way to tell CMake (2.8.1) to set the correct Platform SDK in the project. No plan how to do this...
I would appreciate any help. 2010 is somewhat mandatory unfortunately, I personally cannot get used to it at all...
Ok, updating to the latest CMake (2.8.12) resolved this, CMake now detects the 7.1 SDK and sets it in the project files.
Edit: The toolset can be chosen in a CMake file via the CMAKE_GENERATOR_TOOLSET flag
I am having trouble getting x64 compilation to work on Windows 7 RTM (64-bit) with Visual Studio 2008 Professional (both with and without SP1). I have not installed the Windows 7 SDK, as Microsoft suggests might be the issue. The problem is that there are no x64/64-bit choices in the Configuration Manager of Visual Studio.
I do not have the "Microsoft Visual C++ Compilers 2008 Standard Edition" suggested in the link above installed on my computer. Any ideas what might fix this?
I have checked that I have the x64 compiler and tools installed with Visual Studio.
Solution found: Uninstall VS completely and reinstall. Issue resolved after SP1 installed (again). Very strange.
Are you using VS 2008 Express Edition?
You can add the x64 targets to the build configuration manually by downloading the Windows SDK (which include all the x64 compilers/linkers/libs/headers/... ) and following the instructions in this link:
http://jenshuebel.wordpress.com/2009/02/12/visual-c-2008-express-edition-and-64-bit-targets/
EDIT
Did you make sure to include the 64 bit toolset as part of the Visual Studio install? This toolset is an optional component that can be disabled during the initial install process. I believe you can add it back in by going through a Visual Studio repair process.
Original Answer
Are you using a clean windows 7 RTM install or did you upgrade from a previous version? There is at least one issue being reported by Visual Studio customers who upgraded an earlier build of Windows 7 to RTM.
Other, seemingly unrelated issue
http://www.hanselman.com/blog/VistaUsersUninstallVisualStudio2010Beta1BeforeUpgradingToWindows7.aspx