[cmake-developers] [CMake 0015622]: Add support for 64-bit Visual Studio Toolchains
Mantis Bug Tracker
mantis at public.kitware.com
Wed Jun 17 22:39:44 EDT 2015
The following issue has been SUBMITTED.
======================================================================
http://www.cmake.org/Bug/view.php?id=15622
======================================================================
Reported By: Paul "TBBle" Hampson
Assigned To:
======================================================================
Project: CMake
Issue ID: 15622
Category: CCMake
Reproducibility: N/A
Severity: feature
Priority: normal
Status: new
======================================================================
Date Submitted: 2015-06-17 22:39 EDT
Last Modified: 2015-06-17 22:39 EDT
======================================================================
Summary: Add support for 64-bit Visual Studio Toolchains
Description:
Visual Studio 2013 onwards have added a property to MSBuild
"PreferredToolArchitecture" which can be set to "x64" to use the 64-bit compiler
toolchain. This toolchain can produce all the same output targets: Win32, x64
and ARM; as the default (32-bit) compiler toolchain can.
It'd be great if this was supported somehow in CMake. Now that we have the -A
flag for output architecture from the Visual Studio generators, this might be a
duplicated set of generators, which only support -A for output architecture
support. If there is an appropriate CMAKE property, that'd work too.
Ideally, we could flag off CMAKE_SYSTEM_PROCESSOR and
CMAKE_HOST_SYSTEM_PROCESSOR to control this sort of cross-compiler behaviour,
except that would:
(a) introduce a behaviour change for existing projects (hence perhaps a Visual
Studio generator-specific policy); and
(b) require "fixing" CMAKE_SYSTEM_PROCESSOR, see issue
http://www.cmake.org/Bug/view.php?id=15170
"PreferredToolArchitecture" is safe to set to "x64" on 32-bit platforms, as the
VS2013 MSBuild scripts detect when the build is run on a 32-bit host or without
the 64-bit toolset installed, and (silently) fall back to the 32-bit toolset.
As a workaround, "PreferredToolArchitecture" can be set as an environment
variable, in case anyone finds this feature request and doesn't want to wait for
implementation.
Additional Information:
MSBuild documentation at
https://msdn.microsoft.com/en-us/library/dd293607(v=vs.120).aspx shows this flag
for VS2013 and VS2015 RC.
In VS2010 and VS2012, you could set the property "_IsNativeEnvironment" to
"true" to use the 64-bit toolchain. This was not formally documented on MSDN,
but in various blog posts. Anecdotally, it didn't support cross-compiling 32-bit
or ARM targets from the 64-bit toolchain.
The "_IsNativeEnvironment" property is actually an internal property for the
MSBuild C++ targets, but you must set it manually in pre-VS2013 because the IDE
is always 32-bit and always provides the PROCESSOR_ARCHITECTURE environment
variable as "x86". The actual intent of the toolchain code was to detect and
enable _IsNativeEnvironment when running from a 64-bit environment, as seen in
this snippet:
<_IsNativeEnvironment Condition="'$(PROCESSOR_ARCHITECTURE)' == 'AMD64' and
'$(Platform)' == 'X64'">true</_IsNativeEnvironment>
<_IsNativeEnvironment Condition="'$(PROCESSOR_ARCHITECTURE)' == 'IA64' and
'$(Platform)' == 'Itanium'">true</_IsNativeEnvironment>
See
https://social.msdn.microsoft.com/Forums/en-US/d6b352ea-12b6-4867-b86d-a052fbab1da4/how-can-switch-to-native-x64-compiler-to-compile-x64-program
for discussion.
This logic is still present in VS2013, but the "PreferredToolArchitecture"
presents the user-selectable interface. VS2013 attempts to honour the
"_IsNativeEnvironment" property and set "PreferredToolArchitecture" to match,
but apparently that doesn't work, see
https://connect.microsoft.com/VisualStudio/feedback/details/800059/isnativeenvironment-true-no-longer-works-on-visual-studio-2013-rc
A request for this appeared on Stack Overflow at
http://stackoverflow.com/questions/23186620/use-native-64bit-toolset-in-visual-studio-2013
and a CMake mailing list request for a workaround at
http://www.cmake.org/pipermail/cmake/2014-February/057045.html
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2015-06-17 22:39 Paul "TBBle" HampsonNew Issue
======================================================================
More information about the cmake-developers
mailing list