I use Visual Studio 2017. In a project (that I target as x64), I get error : C1060, compiler is out of heap space, and sadly learned there happen to exist a memory limitation for compilation.
When monitoring CL.exe, it indeed stop just before reaching 4GB. So it looks like CL.exe is by default a 32bits application, as seen at : https://learn.microsoft.com/en-us/cpp/build/how-to-enable-a-64-bit-visual-cpp-toolset-on-the-command-line
After reading this page, I installed "Universal Windows Platform workload" hoping to get access to a 64 bit version of CL.exe. But no change when compiling my project, and I can't see a single option in visual studio to choose compiler version.
I assume that there must exist a workaround to be able to use more than 4GB for a single compilation unit, but I couldn't find it for now. Any help would be much appreciated.
Edit : I hit limitation in Debug mode. Compilation is doing fine in Release mode. Which is suppose makes sense.
By default Visual Studio uses the 32-bit toolchain (i.e. the compiler is 32-bit and cross-compiles 64-bit executables). Visual Studio 2015 and 2017 include both 32-bit and 64-bit versions of all the compilers (x86, x64, arm, arm64).
You can opt-in to using the 64-bit toolchain on a 64-bit system by two methods:
Add a environment variable on your build machine (either system-wide or from a VS Developer Command Prompt).
For example:
set PreferredToolArchitecture=x64
devenv
You can edit your vcxproj files to do this as well with the <PreferredToolArchitecture>x64</PreferredToolArchitecture> element:
For example:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
<UseDebugLibraries>true</UseDebugLibraries>
<PlatformToolset>v141</PlatformToolset>
<PreferredToolArchitecture>x64</PreferredToolArchitecture>
<CharacterSet>Unicode</CharacterSet>
</PropertyGroup>
I use the second method in the UWP (C++/WinRT) versions of my Direct3D Game VS Templates, and I just noticed that I should add it to my UWP (C++/CX) and Win32 versions. The Xbox One XDK automatically does this in it's platform build rules as well.
Note this question has been answered in the past: How to make Visual Studio use the native amd64 toolchain
Related
I'm trying to build binary files of the LAPACK 3.7.0 using CMAKE based on what is told here. In order to use them in my Visual Studio 2013 C++ project.
But I really don't know which option should I choose here?
And also which compilers should I choose in the following?
Because I can't find them in the suggested directories within Program Files or Program File(x86) folders.
my machine uses a dual-core Intel(R) Core(TM) 2 Duo CPU
When using Visual Studio < 2015, a common solution is to run CMake GUI from Visual Studio Command line.
Use windows start menu to run "Visual Studio Command Prompt"
Run cmake-gui from command line. If the folder is in your path, simply launch cmake-gui. If not, launch it using the full path
Locate the source folder of your project (the folder containing the top-level CMakeLists.txt) and create a new build folder (ex c:/my-project/build_32). Generating an environment in the source folder is discouraged)
Generate your project selecting the right MSVC version. In your case, it will be "Visual Studio 12 2013". In my case, this is MSVC 2010.
That's all. Click on finish button and it should generate the compilation environment, solutions, projetcs, etc.
This will generate environment for compiling x86 application. If you also need to compile a x64 version of your project, simply follow again that process, generating in a new build folder and selection "Visual Studio 12 2013 Win64".
By default, if you have a paid version of Visual Studio you have both x86 and Win64 compiler installed. If you have the express version, you only have the x86 compiler (so generation using MSVC Win64 will fail).
Currently I'm working with Visual Studio 2015 on a 32-Bit computer and create 32-bit applications in C++/CLI.
As far as I remember one could choose between creating 32 and 64-Bit applications in previous Visual Studio versions, if one has installed the 64-Bit compiler too.
Today I was trying to get the same functionality out of the 2015's version of Visual Studio, but I'm not able to find any option to install the 64-Bit compiler.
In the compiler-settings I can only choose between ARM and 32-Bit (no 64-Bit, no "any platform"). Running the Visual Studio Setup from the Windows system preferences also shows no possibility to install the 64-Bit compiler (or maybe i just don't know what to install).
QUESTION: How can I install the 64-Bit C++ compiler for Visual Studio 2015 on a 32-Bit computer?
#GSerg gave the aswer I needed in his first comment - thank you for your help!
The compiler seems to be installed by default. I just wasn't able to find the way to set the platform.
i get the following error when i try to run an exe on a x64 machine that was build for x86 CPU using the MC++ compiler (vs2010) on a x86 machine:
i already have visual studio 2012 (along with Visual C++ 2012 Update 4 redistributable- both x86 and x64) installed on this second (x64) machine.
A quick search tells me the "MSVCR100.dll" is already present in "C:\Windows\System32".
i tried to install the Microsoft Visual C++ 2010 Redistributable but it exited with an error telling me that a superior version is already installed.
Please guide me what i am doing wrong. :)
Firstly, in 64-bit versions of Windows, 32-bit system executables and application extension files (aka DLLs) are placed in %systemroot%\SysWOW64 instead of %systemroot%\System32 (which, somewhat counterintuitively, contains 64-bit versions in a 64-bit Windows). So the SysWOW64 folder has to be checked for the x86/32-bit MSVC(++) DLLs.
Secondly, though installation of the corresponding visual studio version on the target machine or having accompanied the distributed program with the required C(++) DLLs should, theoretically, solve the problem, it's not necessary. It's sufficient to have the corresponding MSVC++ redistributable package installed (i.e. e.g. Microsoft Visual C++ 2010 x86 redistributable package in this particular case).
Notes:
The aforementioned info are theoretically correct but damaged Windows installations or ... may not conform.
Including the C++ DLLs with the distributed program is acceptable (and possibly a conservative but correct decision) but installing a Visual Studio version solely to be able to use the DLLs in question definitely isn't.
As a side note, C++ redistributable packages don't install the debug versions of the DLLs so installation of or access to a corresponding Visual Studio version is necessary for running debug-compiled applications.
Your application needs the dll for VS2010. you should place MSVCR100.dll and MSVCP100.dll from your x86 machine beside your exe. You can also install VS2010 alongside your current VS2012. then you should also install the Service Pack1 for VS2010 to work properly. After installing VS2010 you have access to both mentioned dlls and also you probably don't need to copy them to your exe directory.
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.
I installed Visual Studio 2008 on my Windows 7 x64 laptop together with installation of Service Pack 1.
Now I want to add x64 platform to my C++ solution. But there is no x64 platform available in the configuration manager for my project. I'm sure I manually selected x64 support during the Visual Studio installation and it was installed.
What is wrong with my setup?
If I recall, VS 2008 Pro doesn't install the 64-bit compiler and tools by default. You have to explicitly select them during the installation.
Control Panel -> Uninstall Programs.
Select Visual Studio and click Uninstall/Change.
Wait. Wait some more. Click Next.
Choose Add or Remove Features.
Expand MSVC 2008 -> Language Tools -> Visual C++.
Select X64 Compilers and Tools.
You'll probably need your original installation media.
Once the 64-bit compiler and tools are installed, you should be able to add a 64-bit configuration to your solution.
See "Use Visual Studio to build 64-bit application" for all you need to build x64 apps with Visual Studio 2008.
Visual Studio 2008 only comes with x64 compiler with the Professional editions and higher. You can download the free Windows SDK from MSDN to get the x64 compiler.
If your projects don't have the x64 configuration, just add that configuration via the configuration manager. I don't remember if 2008 created the x64 configuration by default but I suspect not.
I also seem to remember that you can just add the x64 configuration to the solution and it will prompt on whether or not to add it to all of the contained projects but my memory is rusty on that one.
Regardless, once you've got the configurations added, you'll need to modify anything you'd modified before in project settings. Output paths, library dependencies, etc. The New Configuration "Wizard" is pretty dumb.