Notes
(0035095) Brad King (manager) 2014-02-12 15:32	The MSVC compiler command-line tool cannot be run from an arbitrary environment. It wants vsvars32.bat or equivalent to be loaded. Are you launching CMake from such a command prompt? This is normally not necessary for the VS IDE generators but if you want execute_process to be able to run 'cl' you need to do it or create your own wrapper .cmd command to do it and then run that with execute_process.

(0035102) N. Thompson (reporter) 2014-02-13 11:06	The machine this runs on has VS 2010, 2012 and 2013 installed. As mentioned, we run the appropriate “vcvars” script for the environment of interest whenever we want to do something from command line because these different environments are not visible in the path. However, also as you said, this is not normally needed when running CMake with the Visual Studio Generators. Our experience is that we are able to run this build from the command line or from the Cmake-gui without setting the path in advance. It works for 32-bit and 64-bit builds for VS 2010 and 2012. However, something appears to be different with respect to VS 2013 64-bit builds. Only the 32-bit build works for VS 2013. The VS 2013 64-bit build results in this bizarre pop-up error. Perhaps this is just a case of us being lucky over the years when we ran cl.exe using execute_process without a wrapper that sets up the execution environment. But, when we first tried it and it worked we probably just assumed that CMake had the compiler environment all figured-out and setup for the generator in question and we never realized that our code was working for all the wrong reasons. But I understand also that Microsoft has moved some tool components around in VS 2013 so that things are not located where they used to be located. Probably the only way to tell what is going on is to compile a debug version of CMake and run it under the debugger and compare the VS 2012 Win64 environment when cl.exe is run from execute_process to the VS 2013 Win64 environment. I am not sure that I have the wherewithal to do that.

(0035104) Brad King (manager) 2014-02-13 14:04	Re 0014752:0035102: Thanks for the explanation of your set up. I think it has been working by luck until now. CMake makes no attempt to configure the execute_process environment when running a compiler tool. I haven't tested myself from the description it sounds like "cl" now requires some DLLs to be available which aren't without the proper environment. Perhaps before "cl" didn't have this requirement and would run but just not have the INCLUDE and LIB environment set up properly. You can try running "set" or "cmd /c set" through execute_process to see the environment.

(0035109) N. Thompson (reporter) 2014-02-14 13:40	We modified our CMake script to capture the environment variables by running execute_process() with “cmd.exe /c set” as you suggested. We did this for the four generators Visual Studio 2012, Visual Studio 2012 Win64, Visual Studio 2013 and Visual Studio 2013 Win64. We compared the four environments but none of us here have a PhD in Microsoft Studies so it is not so easy to spot irregularities. Subtle differences exist but nothing stands out as being profoundly wrong to the layman’s eye. Three of these generators work perfectly as I said in the previous postings. Only the 64 bit generator for VS 2013 fails. So, we took the environment variables from the log file for the failed execute_process() command and used them to duplicate the same environment at a windows command prompt. We confirmed that we had precisely the same environment by first deleting all environment variables so that the SET command produced an empty list and then we set only those variables that were in effect for the VS 2013 Win64 generator. When we ran cl.exe at the command prompt after setting the exact same environment, we get the following response without the error: Microsoft (R) C/C++ Optimizing Compiler Version 18.00.21005.1 for x64 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] If we comment-out the failing execute_process() command in our problematic build script then CMake runs to completion and configures a build environment for VS 2013 x64 that is fully functional and works using msbuild from a command-line or via the IDE. Thus we conclude that the VS 2013 installation is OK. It is just not possible to run the cl.exe compiler from execute_process() although the environment appears to be fine. Since we are effectively using “undocumented features” of CMake, probably this is as far as this investigation will go.

(0035110) Brad King (manager) 2014-02-14 13:45	Re 0014752:0035109: It may have something to do with launching from a 32-bit cmake process as against the 64-bit cmd prompt. As you pointed out in the initial report: > sometimes these errors are caused by the improper use of 32bit/64 bit DLLs.

(0035143) N. Thompson (reporter) 2014-02-18 15:50	1. CMake source was downloaded and compiled using Visual Studio 2013 as a 64-bit debug application. 2. The problematic CMake script was run using the 64-bit cmake.exe application and the problem persisted. It was not possible to run the CMAKE_CXX_COMPILER compiler via the execute_process command during the configuration phase. 3. The problematic CMake script was modified to pass the CMAKE_CXX_COMPILER variable to a Windows script (batch file) and to examine the environment within the script. 4. It was determined that the CMAKE_CXX_COMPILER variable always points to a 32-bit (x86) version of cl.exe within the Visual Studio binary (bin) directory tree although the running machine is a 64-bit platform, the build target is 64-bit application and cmake.exe itself is a 64-bit application. This issue was investigated further. 5. It was confirmed that the Visual Studio environment must be properly setup before running cmake.exe if execute_process is to be used within a CMake script to run the CMAKE_CXX_COMPILER. If the path is clean of all visual studio binary files than the execute_process command will fail with a missing DLL message. The execute_process command within a CMake script appears to run with the exact same environment that is in effect when cmake.exe is run. 6. Since the problematic script was running cmake.exe to configure a build for a 64-bit target, the environment had been setup using the “vcvarsall x64” command before cmake.exe was started. This placed 64-bit Visual Studio 2013 binaries and DLLs into the path. However, cmake.exe always sets the CMAKE_CXX_COMPILER variable to point to the x86 cl.exe cross compiler in the Visual Studio binary tree at ../bin/x86_amd64/cl.exe. When the execute_process command was run, it was passed the fully qualified name of the 32-bit, x86 cross-compiler. This caused a problem under Visual Studio 2013 because of a mismatch of the 32-bit compiler with the 64-bit DLLs - but not under Visual Studio 2012 or Visual Studio 2010. Or at least this appeared to be the root of the problem. 7. Under VS 2013, the 32-bit x86 cl.exe cross compiler would not run when the environment pointed to 64-bit DLLs. Under VS 2010 and VS2012 the 32-bit x86 cl.exe cross compiler would run normally when the environment pointed to 64-bit DLLs. The precise DLL or list of DLLs that cause the problem was never determined. 8. When the environment was changed using “vcvarsall x86” before calling cmake.exe then the problem disappeared. When the execute_process command ran, the cl.exe 32-bit cross compiler was successfully able to run because the DLLs in the path were 32-bit DLLs. 9. It was not possible to determine why this is only a problem with Visual Studio 2013 and why it is not a problem for Visual Studio 2010 and Visual Studio 2012. 10. Unfortunately, by unconditionally setting-up the 32-bit Visual Studio environment before calling cmake.exe, the option to perform a nmake build was broken. To configure a build using nmake it is necessary to setup the environment before calling cmake.exe to be that of the build target. For this problem being discussed, the build target is a 64-bit application so it is necessary to setup the 64-bit environment before running cmake.exe – but this breaks the Visual Studio build.

(0035148) Brad King (manager) 2014-02-19 08:28	Re 0014752:0035143: > cmake.exe always sets the CMAKE_CXX_COMPILER variable to point to the x86 cl.exe The path to the compiler is detected based on the environment within VS IDE builds. The compiler id test project has a post-build event to print out the location of "cl" in the PATH: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CompilerId/VS-10.vcxproj.in;hb=v2.8.12.2#l44 [^] The output line is parsed here: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineCompilerId.cmake;hb=v2.8.12.2#l162 [^] to extract the path to the compiler.

(0039576) milk (reporter) 2015-10-12 12:32	This behavior of cmake still exist in version 3.2.3. For example you can reproduce it by compile OpenCV by MSBuild from command line. I can override this behavior by using "vcvarsall x86_amd64" environment. i'am using stock x86 build of cmake from site on x64 Windows 7 and Visual Studio 2013. I think cmake should detect compiler as "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\cl.exe" rather than "...\x86_64\cl.exe"

(0039690) Braden McDaniel (reporter) 2015-10-27 22:17	I'm seeing this as well. It seems to be evident on MSBuild usage, rather than building the project/solution using devenv. To reproduce this, call "vcvarsall amd64", run cmake, then build the resulting solution with msbuild. msbuild will fail with a bunch of error messages about not being able to locate cl.exe. It does seem as though CMake is pointing at the wrong toolchain in this case.

(0039694) Brad King (manager) 2015-10-28 08:29	Re 0014752:0039690: Thanks. Is 0015622 related?

(0039699) Braden McDaniel (reporter) 2015-10-28 12:35	Very likely related; though I'm not 100% sure. The crux of the problem I'm hitting is this: I cannot find any way to use the 64-bit toolchain when using MSBuild with CMake-generated project files. I've tried adding "/p:UseNativeEnvironment=true", "/p:_IsNativeEnvironment=true", and "/p:PreferredToolArchitecture=x64" to the MSBuild command line after calling "vcvarsall amd64"; and all result in the "failed to locate cl.exe" error message. I've even tried doctoring the project files emitted by CMake to add "<UseNativeEnvironment>true</UseNativeEnvironment>". That, alas, doesn't work with MSBuild, either; but it does appear to work if the project files are built with devenv instead. FWIW, I'm using VS2013.

(0042484) Kitware Robot (administrator) 2016-06-10 14:29	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2014-02-12 15:19	N. Thompson	New Issue
2014-02-12 15:32	Brad King	Note Added: 0035095
2014-02-13 11:06	N. Thompson	Note Added: 0035102
2014-02-13 14:04	Brad King	Note Added: 0035104
2014-02-14 13:40	N. Thompson	Note Added: 0035109
2014-02-14 13:45	Brad King	Note Added: 0035110
2014-02-18 15:50	N. Thompson	Note Added: 0035143
2014-02-19 08:28	Brad King	Note Added: 0035148
2015-10-12 12:32	milk	Note Added: 0039576
2015-10-27 22:17	Braden McDaniel	Note Added: 0039690
2015-10-28 08:29	Brad King	Note Added: 0039694
2015-10-28 12:35	Braden McDaniel	Note Added: 0039699
2015-10-28 12:56	Brad King	Relationship added	related to 0015622
2016-06-10 14:29	Kitware Robot	Note Added: 0042484
2016-06-10 14:29	Kitware Robot	Status	new => resolved
2016-06-10 14:29	Kitware Robot	Resolution	open => moved
2016-06-10 14:29	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed