7

Visual Studio 2012 seems to always call the 32-bit version of cl.exe located at %ProgramFiles(x86)%\Microsoft Visual Studio 11.0\VC\bin\x86_amd64) instead of the 64-bit one located at %ProgramFiles(x86)%\Microsoft Visual Studio 11.0\VC\bin\amd64.

I tried prepending $(VCInstallDir)bin\amd64 to the beginning of the "Executable Directories" list in the VC++ Directories section of the Microsoft.Cpp.x64.user property sheet, but that doesn't work at all -- when I rebuild I get this error:

TRACKER : error TRK0002: Failed to execute command: "
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64\CL.exe"
@C:\Users\<my_profile>\AppData\Local\Temp\tmpf3d817cafe064ad28e7dd62b2cb591c3.rsp
". The operation identifier is not valid.

How can I make Visual Studio 2012 use the native 64-bit C++ compiler?

JWWalker
  • 22,385
  • 6
  • 55
  • 76
user541686
  • 205,094
  • 128
  • 528
  • 886
  • Is the question out of plain curiosity or are you asking because my reason for doing this actually affects the procedure for fixing the IDE? – user541686 Jan 07 '13 at 00:58
  • Just plain curiosity. I can't think of any reason to want to use the native 64 bit compiler. – James Kanze Jan 07 '13 at 11:13
  • @JamesKanze: Microsoft made it for a reason ;) I need to see if it can compile some of my projects faster. – user541686 Jan 07 '13 at 18:23
  • 3
    64 bit mode is normally slower than 32 bit. You use 64 bit mode because your program is running out of space. If you have C++ sources which can't be compiled with the 32 bit compiler because of a lack of space... those are some pretty big programs. – James Kanze Jan 07 '13 at 19:23
  • @JamesKanze: Have you ever tried compiling Chromium? – user541686 Jan 07 '13 at 19:24
  • Did you ever figure this out? I was told by VS developers at BUILD 2013 that if we use the native x64 compiler (vs cross-compiler) the incremental linking feature will have to do a full link less-often. So, yes, this is a useful exercise but I'm hitting the same error. Unfortunately, we did not have time to try it in the demo area at BUILD. – jschroedl Jul 08 '13 at 19:44
  • I have recently needed to force usage of the 64-bit linker because the 32-bit linker was thrashing to save memory while linking a big project. The 64-bit linker has more relaxed constraints and can make better use of available RAM. If you throw in a few boost libraries, and enable iterator debugging then it's quite easy to get up to libraries of 800Mb+, even though the linker will finally boil it down to an executable of 10Mb – the_mandrill Sep 03 '14 at 09:13

2 Answers2

13

This answer is a bit late to the party, but frustratingly there's still no good resource directly available from Microsoft's online documentation. It turns out to be easy, even if not totally convenient.

At the command prompt, type (changing the version of VS to your needs):

> set _IsNativeEnvironment=true
> "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" YourProject.sln

The clue for this is in the file

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.targets

where it says

<SetEnv Condition="'$(_IsNativeEnvironment)' == 'true'"
        Name ="PATH"
        Value ="$(NativeExecutablePath)"
        Prefix ="false">
  <Output TaskParameter="OutputEnvironmentVariable" PropertyName="Path"/>
</SetEnv>

My project is generated by CMake, so I am usually at the command prompt for a few lines before I can open VS anyway. I have always started my CMake generators after first setting up the MSVC environment, so I honestly don't know if it's required or not, but you can optionally also do (before everything else):

> call "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" amd64

and /or

> call "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64\vcvars64.bat"

Here's the link to the original post on MSDN where I finally found the answer.

user541686
  • 205,094
  • 128
  • 528
  • 886
Tanaya
  • 396
  • 4
  • 11
  • 4
    Update: For VS2013, the environment variable has changed. It's now: 'set PreferredToolArchitecture=x64' See [link](https://connect.microsoft.com/VisualStudio/feedback/details/800059/isnativeenvironment-true-no-longer-works-on-visual-studio-2013-rc) – Tanaya May 12 '14 at 21:55
  • 1
    In VS2013 there's also a mechanism to set the change in the vcxproj file -- see http://stackoverflow.com/a/25626630/188414 – the_mandrill Sep 03 '14 at 09:10
0

I was converting an old project from Win32 to x64 and came across this problem.
I found two different ways on how to go around this:

Method 1:
i. Got to: Project properties | General | Platform Toolset
ii. Change the value from 'Visual Studio 2012 (v110)' to 'Visual Studio 2012 - Windows XP (v110_xp)'

Mehtod 2:
i. Open configuration file %LOCALAPPDATA%\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props
ii. Inside the <ExecutablePath> property group, I replaced the $(WindowsSDK_ExecutablePath_x64) entry with $(WindowsSDK_ExecutablePath_x86)

After any of these all worked fine.

PazO
  • 1,314
  • 1
  • 11
  • 30