I've been trying to compile the Adaptive Communications Environment (ACE) project in MS Visual Studio 17 2022, but have been getting a slew of related linking errors.
Below is an example:
1>C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.33.31629\include\cstdlib(23,41): error C2733: 'abs': you cannot overload a function with 'extern "C"' linkage
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt\corecrt_math.h(464,38): message : see declaration of 'abs'
This issue is obviously not originating in the ACE code, but in the code bundled in with the build tools.
My guess is there is a clash between MSVC 14.33.31629 and Windows Kit 10.
Does any one have any suggestions on a fix? Is there a compiler or pre-processor flag I can use to mitigate this? Should I use different versions of the MS Build Tool or Windows Kit?
I resolved this by upgrading my Windows SDK to version 10.0.20348.0.
I know that for an MFC project built with Visual Studio, one can go to the project properties and then Configuration Properties -> General -> use of MFC and change it to Use MFC in a static library:
This works if the resulting build has to run in earlier versions of Windows without the need to install MFC or VC run-time DLLs. The resulting build will use DLLs that are already present in every installation of Windows since Windows 7 and up. (Possibly even down to Windows XP.)
Now if I create a non-MFC project, say a test C++ console application, the setting to use MFC is configured as "Use standard Windows Libraries":
But if I run the resulting binary file, say on a fresh install of Windows 7, I get this error:
So having dug around the settings, I couldn't find any way to compile it with static linking to all those newer versions of VC RT libraries. Is it there and I just don't see it?
PS. Having dug in further, I found out that I can change the "Platform Toolset" to Visual Studio 2017 - Windows XP (v141_xp), assuming that it will make it backwards compatible with Windows XP and up:
But then if I compile it, I'm getting these errors:
1>c:\program files (x86)\microsoft sdks\windows\v7.1a\include\objbase.h(239): error C2760: syntax error: unexpected token 'identifier', expected 'type specifier'
1>c:\program files (x86)\microsoft sdks\windows\v7.1a\include\dbghelp.h(1540): warning C4091: 'typedef ': ignored on left of '' when no variable is declared
1>c:\program files (x86)\microsoft sdks\windows\v7.1a\include\dbghelp.h(3056): warning C4091: 'typedef ': ignored on left of '' when no variable is declared
In this part of ObjBase.h file which has nothing to do with my test C++ console project that I just created from a Visual Studio template:
So my question is -- can I build a non-MFC C++ project that can run on older versions of Windows without the need to install VC Runtime or any other additional libraries?
Go to C / C++ -> Code Generation. Set Runtime library to Multi-threaded /MT instead of Multi-threaded Dll /MD
I am getting following error on VC2010-SP1 Win7 32-bit. I tried for HotFix but it is no longer available here https://support.microsoft.com/en-us/kb/982517. Can anyone help? Thanks
ClCompile:
stdafx.cpp
C:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\include\atlcomcli.h(1751): error C2338: CVarTypeInfo< char > cannot be compiled with /J or _CHAR_UNSIGNED flag enabled
C:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\include\atlcomcli.h(1774): error C2338: CVarTypeInfo< char* > cannot be compiled with /J or _CHAR_UNSIGNED flag enabled
c:\Program Files\Microsoft SDKs\Windows\v7.0A\include\odbcss.h(430): error C2371: 'WCHAR' : redefinition; different basic types
c:\Program Files\Microsoft SDKs\Windows\v7.0A\include\winnt.h(344) : see declaration of 'WCHAR'
Build FAILED.
I tried for HotFix but it is no longer available here https://support.microsoft.com/en-us/kb/982517.
It's still available, but listed as requiring a support call (as many KBs do by default). You can however ask for a download link by email.
Since you run SP1 of VS2010, KB 982517 points to KB 2545588 for the fix. Following How can you download a hotfix without contacting Microsoft? which still works nowadays, click...
http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2545588&kbln=en-us
...accept the terms, and provide a valid email where you'll receive the download link. Be prepared for a massive download to the tune of 270+ MB. If the hotfix doesn't fix it, or breaks anything else, don't expect much support from MS (since you just agreed to their terms in a previous step ;-)).
I'm trying to build a Windows Universal app using cl.exe from the command line. I've pasted in the command line parameters from one of the Visual Studio templates, but I still can't get it working. I get the following error:
F:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\vccorlib.h(348): error C3940: 'EventRegistrationToken': identifier not found - possible mismatch between compiler and library versions. Please ensure vccorlib.h/.lib, vccorlib120.dll and c1xx.dll match
It appears that it is using the wrong include libraries.
The cl.exe command line also includes the following options for include files:
/LIBPATH:"F:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\lib\store\amd64"
/LIBPATH:"F:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\lib\amd64"
Fixed this by running vcvarsall.bat with the appropriate option, beforehand.
How can I get Visual Studio 2012 to use the native amd64 toolchain, rather than the default x86_amd64 cross-compiler?
I am building a large library that causes the linker to run out of memory when doing whole program optimization and link-time code generation.
I found two older posts (here and here) asking this same question, but no answers yet. Microsoft provides documentation on how to specify the toolchain on the command line, but not in the IDE.
There is another method of forcing use of the 64-bit linker on a per-project basis for Visual Studio 2013. Edit your .vcxproj file and insert the following after the <Import...Microsoft.Cpp.Defaults line:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup>
<PreferredToolArchitecture>x64</PreferredToolArchitecture>
</PropertyGroup>
You need to set the environment variable "_IsNativeEnvironment" to "true" prior to starting Visual Studio 2012 IDE:
set _IsNativeEnvironment=true
start "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" your_solution.sln
For Visual Studio 2013, the name of the environment variable is different:
set PreferredToolArchitecture=x64
sbm start "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" your_solution.sln
Beware that this technique does not work if the version of the IDE does not match the version of the toolchain. That is, if you use VS2013 IDE configured to run VS2012 compiler, you are out of luck. But such combination is uncommon.
Here are some links for further information:
difference between VS12 and VS13
how to embed PreferredToolArchitecture into the project in VS13
If your goal is to use the native environment rather than specifically amd64_x86, you can set the UseNativeEnvironment property in your project file:
<PropertyGroup>
<UseNativeEnvironment>true</UseNativeEnvironment>
</PropertyGroup>
(I have successfully added it to the "Globals" PropertyGroup.)
You can check which toolchain is being used by adding the /Bv compiler option. Example output is below. Notice that the toolchain directory appears after bin\ (amd64_x86 in this case).
2>ClCompile:
2> Compiler Passes:
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\CL.exe: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1xx.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c2.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\link.exe: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\mspdb120.dll: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\1033\clui.dll: Version 18.00.31101.0
I know this is a rather old post, but it's still relevant for VS 2017. Here you also have the "PreferredToolArchitecture" environment variable and a "build in" setting in the IDE is not readily available.
However you can integrate that easily on a project by project base so that you can always chose what tool architecture to use. Maybe this is helpful for some. Do this:
Go to Property Manager and create a new property sheet, e. g. named "x64 Toolchain.props" so you know what it does. With a separate property sheet you can then switch the tool architecture as appropriate by including or not including the sheet into a project.
Open the properties of that new sheet, navigate to "Common Properties\User Macros" and click "Add Macro".
In the dialog you set the name to "PreferredToolArchitecture", the value to "x64" and enable the checkbox "Set this macro as an environment variable in the build environment".
Optionally navigate to "Common Properties\C/C++\Command Line" and add "/Bv" under "Additional Options". This will make the compiler output the tools it uses including its path and version number, might be helpful for checking if really the desired architecture is being used. It will place entries in the log output window like so:
Compiler Passes:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\CL.exe: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1xx.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c2.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\link.exe: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\mspdb140.dll: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\1033\clui.dll: Version 19.15.26730.0
Now for all projects that should be build with the x64 tool architecture include the new property sheet into the project in property manager. And for those that should not simply don't include it. That's it.
HTH
Edit:
It seems unfortunately this is not reliable! See below comments. I would really appreciate if MS would wire this setting to some GUI element and make it work consinstently...
I have a similar problem using Visual Studio 2010 on XP 64 SP2. If I set the VC++ executable directory to the amd64 bin (the native x64 folder) as the first in the search path, then I received the TRK0002 error … Invalid handle value.
But if I set _IsNativeEnvironment=true in a Visual Studio 2010 command prompt and start the ide from the command line as posted before, then the error goes away. Apparently, the 32-bit GUI IDE Environment is receiving info from a 64 bit process and is expecting info from a 32-bit process such as x86\cl.exe or x86_64\cl.exe.
In a scenario where you want to compile an IA64 bit executable, and you use the x86_ia64\cl.exe compiler. Since you are using a 32-bit cross compiler and have the _IsNativeEnvironment variable set to true, this must upset the IDE when posting messages in it's window consoles. Set the _IsNativeEnvironment=false, if you have previously set it to true.
The IDE should pick up that a native compiler was being used on a native 64-bit
machine and should have automatically set this variable to the appropriate value when the native compiler was selected from the IDE. A simple fix has never been applied to patch this problem. Solution. Do it yourself from the prompt, or buy the latest IDE from Microsoft to fix the problem.
So, the real wizards at Microsoft are the developers who work mainly from the command line. And the other developers, who wear the pointy hats and sit in the corner, must have been hired from Apple and were more concerned about appearance than function.
The whole purpose of an IDE is to make coding simple, not more complicated than using a text editor and a Makefile from the command line.