I am using visual studio 2019 with cmake project. When opening cmake settings UI in visual studio IDE, it shows a list of toolset for a C++ project.
From the list of toolsets, I have msvc_x64 and msvc_x64_x64. I want to build on native x64, so I can simply select msvc_x64.
But why there is two toolset named x64 and x64_x64?
Is it the same thing or they are maintaining two names for some sort of backward compatibility?
As per docs, I can understand the naming conventions for toolsets such as msvc_x86_x64, amd64, x64_arm etc.. I would like to learn about x64 and x64_x64 and why these two exist?
Is there any difference between two ? If so can I get some documentation about it?
msvc_x64
This toolset is to target x64 with the x86 version of MSVC.
msvc_x64_x64
This toolset is to target x64 with the x64 version of MSVC.
Related
As I read this article, it is enough to download most recent MSVS 2022 and then install toolset C++ Windows XP Support for VS 2017 (v141) tools [Deprecated].
After that in Visual Studio inside project properties I set this toolset. According to linked article it is enough to compile C++ app with XP support.
But after my .exe file is created if I run it on XP 64-bit SP2 then it shows error that CompareStringEx function is not found in KERNEL32.DLL.
Hence it appears that it is not enough to use this toolset. Something else is needed.
In some other places I see that one needs also to add define /D_USING_V110_SDK71_ when compiling and option /SUBSYSTEM:CONSOLE,5.01 when linking. In my project properties I also tried to add this two options, but still CompareStringEx is inside import table of final application.
As suggested by #BenVoigt, I did defines /DWINVER=0x0502 /D_WIN32_WINNT=0x0502. Also set C++ standard to /std:c++14 (I would set C++11 but this MSVS version allows to set only C++14 at minimum). Still some non-XP symbols remain in final EXE like InitializeSRWLock that is possibly used by C++11's std::mutex in my code.
Does anyone know everything what is needed in order to compile fully XP-compatible application?
Update. I managed to build working XP application by doing things above plus setting C++ CRT runtime to Multi Threaded DLL, i.e. using dynamic DLL linkage of CRT. Also as suggested by #ChuckWalbourn (down x86 or x64 redists), I downloaded older version of msvcp140.dll.
But it is very important for my project to have statically linked runtime (C++ CRT), i.e. use Multi Threaded value for Runtime field in project properties. Only if it is REALLY not possible only then I will use DLL CRT. Until then solution about how to link CRT statically are welcome, of course to produce XP-compatible EXE.
TL;DR For Window XP VC++ REDIST support, install https://aka.ms/vs/15/release/VC_redist.x86.exe on your Windows XP system
-or-
if you are doing "side-by-side application local deployment", then use the DLLs from C:\Program Files\Microsoft Visual Studio\2022\<edition>\VC\Redist\MSVC\14.16.27012\x86\Microsoft.VC141.CRT.
If you want the latest bug fixes to the CRT, you can also download the REDIST for VS 2019 (16.7) per the link on Microsoft Docs.
For Windows XP targeting, you use the v141_xp Platform Toolset installed by Visual Studio (VS 2017, VS 2019, or VS 2022) which is the latest VS 2017 (v141) C++ compiler using an included Windows 7.1A SDK.
Make sure you have installed (for VS 2022) the following individual components since you are using MFC:
Microsoft.VisualStudio.Component.WinXP: C++ Windows XP Support for VS 2017 (v141) tools [Deprecated]
Microsoft.VisualStudio.Component.VC.v141.x86.x64: MSVC v141 - VS 2017 C++ x64/x86 build tools (v14.16)
Microsoft.VisualStudio.Component.VC.v141.MFC: C++ MFC for v141 build tools (x86 & x64)
If you are doing DirectX development, be sure to read this blog post as well for various implications of using the Windows 7.1A SDK.
For deployment to Windows XP, you can install the latest VS 2017 Visual C++ REDIST or use VS 2019 Visual C++ up to VS 2019 (16.7). After that the REDIST DLLs themselves are not compatible with Windows XP.
On your development system with VS 2022 installed, you are going to have a newer set of Visual C++ REDIST files which are binary compatible with your v141_xp Platform Toolset built EXE, but those VC++ REDIST DLLs are not compatible with Windows XP.
IOW: If you look at a dumpbin /imports of the 14.30 (v143 version), 14.29 (v142 latest version), and/or 14.16 (v141 latest version ) copies of msvcp140.dll you will see different imports. The msvcp140.dll sitting in your C:\windows\SysWOW64 folder is going to be the 14.30 version.
I'm trying to build project c++ on vs2017 but there error appear:
"The build tools for Visual Studio 2008 (Platform Toolset = 'v90') cannot be found " after navigation, I must download VS 2008 I have installed it, but problem still exist .
any Suggestion ?
You need:
An MSVC 9.0 compiler toolchain
https://wiki.python.org/moin/WindowsCompilers lists the products that have it:
VS 2008, "Visual C++" feature and "x64 compilers and tools" subfeature
Express edition only has x86 compilers
Do install SP1 on top of VS2008 -- in vanilla VS2008 installer, installation for many features, including x64 compilers, is broken
WinSDK 6.1
WinSDK 7.0
"Visual C++ Compiler for Python 2.7" package
MsBuild 4.0 toolset configuration files for the above toolchain. (These are the directories c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\<arch>\PlatformToolsets\v90\ with .props and .targets files in them)
The only product I know that has this package is VS 2010 ("Visual C++" feature and "x64 compilers and tools" subfeature).
(WinSDK 7.1 technically has it, too, but its setup is riddled with bugs and broken on an x64 system.)
(You can bypass the buggy installer though if you install <GRMSDK_EN_DVD.iso>\Setup\vc_stdx86\vc_stdx86.msi directly. Despite the name, it has toolset files for all 3 platforms.)
"Visual C++ Compiler for Python 2.7" package is not supported by these toolset configuration files. So if you use it, you'll need to either manually specify its location in one of registry values specified in .props, or modify .props to also look in HKLM\Software\Microsoft\DevDiv\VCForPython.
The projects are targeting the v90 platform toolset. The solution is to either open the .sln file with VS2008 (i.e. use the right tool), or spend some time updating the projects to target the latest platform toolset (i.e. VS2017). To do that, just right click each project, and go to Properties, then look at General | Windows SDK Version. You may have to fix compilation / linker errors following the project upgrade.
It is possible to upgrade the project file from the command line without opening it in Visual Studio. I was running into the same issue, and found another solution in the Microsoft documentation for Visual Studio (https://learn.microsoft.com/en-us/visualstudio/ide/reference/upgrade-devenv-exe?view=vs-2017).
Here are the steps:
Open the developer command prompt for you version of Visual Studio, e.g. 'Developer Command Prompt for VS 2017'.
Navigate to the directory of your project file.
Execute the following command: devenv myproject.sln /upgrade
Visual Studio, as of VS2010, supports the concept of multi-targetting, where a solution can be configured for, and built with, the compiler, libraries and includes of preceding Visual Studio versions. For example, the 2010 IDE can be used to build with the v90 (2008) toolset; in 2012 IDE can be used to build with v90, v100, v110 and v110_xp toolchains, and so on.
The question is this; how to configure a CMake build system, already setup to generate solutions for Visual Studio N to build with the compiler etc of Visual Studio N, to permit building with Visual Studio N-M from within the IDE.
While toolset selection should work merely by -T toolset, the issue is that this then in turn provokes a failure in cmake-2.8/Modules/CMakeTestCXXCompiler.cmake , claiming that the cl.exe is not able to compile a simple program. This is not the case, however, in selecting a toolset within a Visual Studio version e.g. v110_xp in Visual Studio 2012. There seems to be some complication in toolsets across Visual Studio versions, as opposed to toolsets within Visual Studio versions.
Does anyone have concrete experience of CMake in this usecase, in generating solutions for toolsets from preceding versions for use in the IDE of the current version of Visual Studio?
That's covered by the CMake's command-line option -T (toolset selection), available since CMake 2.8.11. The syntax is simple:
cmake ... -T "the string VS uses to identify the toolset" ...
So, for example:
cmake ... -T v90 ...
Note that so far, this option does not have a dedicated widget in the GUI.
We have VS2010 pro and Incredibuild 4.62 installed. We are trying to compile to x64 platform, therefore we run
"C:\Program Files (x86)\Xoreax\IncrediBuild\BuildConsole.exe" something.sln /MINWINVER=7 /build release|x64
The issue is that this uses 32 bit cl.exe to compile 64 bit object files, which may be slow and runs into memory issues.
It prints to the console: Setting environment for using Microsoft Visual Studio 2010 x64 cross tools.
It should do x64 tools simply.
My name is Victor and I am from the IncrediBuild support team.
When you are building for the x64 platform in Visual Studio, by default, the compiler that is being used is actually the cross compiler located in the “x86_amd64” folder.
In order to ensure full compatibility to Visual Studio builds, IncrediBuild has to use the same compilers that are being used in Non-IncrediBuild builds.
From our experience – the 32 bit cross compiler and the 64 bit compilers have the same speed, and we have never encountered a state where a compiler running out of memory, so using the native x64 toolset would not yield any benefits.
If however you would like to make the switch to the native x64 toolset – you need to define a new toolset with Visual Studio, which points to the x64 tools.
Once the toolset is defined, and is set to be used in the projects properties - IncrediBuild will use it automatically.
Is there a simple way to compile a 64 bit app with the 32-bit edition of Visual C++ 2010 Express? What configurations, if any, are necessary?
Here are step by step instructions:
Download and install the Windows Software Development Kit version 7.1. Visual C++ 2010 Express does not include a 64 bit compiler, but the SDK does. A link to the SDK: http://msdn.microsoft.com/en-us/windowsserver/bb980924.aspx
Change your project configuration. Go to Properties of your project. On the top of the dialog box there will be a "Configuration" drop-down menu. Make sure that selects "All Configurations." There will also be a "Platform" drop-down that will read "Win32." Finally on the right there is a "Configuration Manager" button - press it. In the dialog that comes up, find your project, hit the Platform drop-down, select New, then select x64. Now change the "Active solution platform" drop-down menu to "x64." When you return to the Properties dialog box, the "Platform" drop-down should now read "x64."
Finally, change your toolset. In the Properties menu of your project, under Configuration Properties | General, change Platform Toolset from "v100" to "Windows7.1SDK".
These steps have worked for me, anyway. Some more details on step 2 can be found in a reference from Microsoft that a previous poster mentioned: http://msdn.microsoft.com/en-us/library/9yb4317s.aspx.
64-bit tools are not available on
Visual C++ Express by default. To
enable 64-bit tools on Visual C++
Express, install the Windows Software
Development Kit (SDK) in addition to
Visual C++ Express. Otherwise, an
error occurs when you attempt to
configure a project to target a 64-bit
platform using Visual C++ Express.
How to: Configure Visual C++ Projects to Target 64-Bit Platforms
Ref:
http://msdn.microsoft.com/en-us/library/9yb4317s.aspx
And make sure you download the Windows7.1 SDK, not just the Windows 7 one. That caused me a lot of head pounding.
I found an important step to add to this - after you've installed the SDK, go to your project properties and change Configuration Properties->General->Platform Toolset from v100 or whatever it is to Windows7.1SDK. This changes $(WindowsSdkDir) to the proper place and seemed to solve some other difficulties I was encountering as well.
Note that Visual C++ compilers are removed when you upgrade Visual Studio 2010 Professional or Visual Studio 2010 Express to Visual Studio 2010 SP1 if Windows SDK v7.1 is installed.
For instructions on resolving this, see KB2519277 on the Microsoft Support site.
Download the Windows SDK and then go to View->Properties->Configuration Manager->Active Solution Platform->New->x64.
Programming in a 64-bit environment is quite different than 32-bit environment.
Code generated has totally different assembly constitution in 32 & 64-bit code, even the protocols of communicating with functions change. So you can't generate 64-bit code using 32-bit compiler.
You might want to see an article on Microsoft's web site about targeting a 64-bit target but using a 32-bit development machine.
As what Jakob said: windows sdk 7.1 cannot be installed if MS VC++ x64 and x86 runtimes and redisrtibutables of version 10.0.40219 are present. after removing them win sdk install is okay, VS C++ SP1 can be installed fine again.
Kind regards