35

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.

Community
  • 1
  • 1
Ky Waegel
  • 353
  • 1
  • 3
  • 8

5 Answers5

40

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>
the_mandrill
  • 29,792
  • 6
  • 64
  • 93
  • 2
    https://connect.microsoft.com/VisualStudio/feedback/details/800059/isnativeenvironment-true-no-longer-works-on-visual-studio-2013-rc – Mark Ingram Jul 20 '15 at 16:06
  • 1
    Just wanted to add, Microsoft is now also recommending this as the way to select the Clang/C2 x64-hosted tools: https://blogs.msdn.microsoft.com/vcblog/2016/06/03/clang-3-8-in-the-may-release-of-clang-with-microsoft-codegen/ – Ross Bencina Sep 28 '16 at 08:12
  • This works but somehow we must specify this setting before the props. – gast128 Mar 22 '19 at 10:10
37

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

Denis Gurchenkov
  • 486
  • 5
  • 3
  • 1
    Is there any way to force this for a specific solution, rather than an environment variable? It would be great if the my build system (CMake) could check and add this option on 64-bit systems. – Ky Waegel May 22 '14 at 04:26
  • 8
    `set PreferredToolArchitecture=x64` works for VS2017 too, thanks! – Serge Rogatch May 26 '17 at 09:50
  • 2
    When using CMake, use "host=x64" when specifying the Visual Studio generator. – Brent Sep 15 '18 at 16:33
10

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
Ross Bencina
  • 3,822
  • 1
  • 19
  • 33
1

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...

Don Pedro
  • 335
  • 3
  • 7
  • Did you test this? I find it has no effect (tested on VS2017 and 2019 on two machines). Setting "PreferredToolArchitecture=x64" as an environment variable before starting VS does (at the command prompt), but not via a "User Macro" in the VS Property Manager (even when the "Set this macro as an environment variable in the build environment" setting is on). Go figure. – Larry May 23 '19 at 15:02
  • I remember testing this when I wrote it on SO, sure. Unfortunately I retested and could not reproduce functionality now, no idea why :-/ MS is really kind of weird here. They still don't offer an "official" way to set this in VS, despite the fact that developers more and more often run into the issue. On the contrary, when using TFS to do automated builds you have a drop down box in the job's settings where you can select which toolchain to chose. And TFS automated builds also ignore settings done elsewhere, so you manually have to make sure settings do match. This is not usability friendly! – Don Pedro May 28 '19 at 07:33
  • Edited the original post to give a hint on the problems involved, namely inconsistent and unplausible behavior – Don Pedro May 28 '19 at 07:37
  • 3
    Thanks for the feedback. Finally (officially), it just became available in the IDE in VS 2019 (V16.1). Under project properties select "Configuration Properties -> Advanced -> Preferred Build Tool Architecture". Note that manually adding the "PreferredToolArchitecture" property to the ".vcxproj" file, as cited by people sometimes (because it's from MSFT's own docs), are *incorrect*, which they acknowledged in a bug report I posted: https://developercommunity.visualstudio.com/content/problem/580850/preferredtoolarchitecture-property-in-vcxproj-file.html?childToView=588144 – Larry May 30 '19 at 02:09
  • 1
    Excellent observation! But it should be noted that the "Advanced" item in the properties dialog is available only when using the VS 2019 toolchain. For older toolchains (which you may use from the VS 2019 IDE) MS did not add this property, despite the fact that older versions already support an x64 compiler/linker. – Don Pedro Jan 20 '20 at 13:55
0

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.

Henry Garcia
  • 31
  • 3