MantisBT - CMake
View Issue Details
0013131CMakeCMakepublic2012-04-13 19:142016-06-10 14:31
Kitware Robot 
x86 Install (x64 Native)Windows7
0013131: Windows CMake may not run safely at a Cygwin prompt
When I try to use CMake to generate Visual Studio 2010 project files, I get the issue as outlined in the Additional Information section below. I tried on 2.8.7 and 2.8.8-rc2 and get the same result. Happens with ANY CMakeLists.txt file, even one that only has the single line "cmake_minimum_required(VERSION 2.8)".
1. Install CMake 2.8.7 for Windows x86.
2. Create file with just "cmake_minimum_required(VERSION 2.8)" inside it.
3. Open Visual Studio 2010 Command Prompt.
4. Navigate to folder.
5. Type "cmake ."
C:\Server Storage\Projects\- Personal Projects\0x10c\kernel\cmake>cmake --debug-trycompile -G "Visual Studio 10" "C:\Ser
ver Storage\Projects\- Personal Projects\0x10c\kernel\cmake"
debug trycompile on
-- Check for working C compiler using: Visual Studio 10
-- Check for working C compiler using: Visual Studio 10 -- broken
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
  The C compiler "C:/Program Files (x86)/Microsoft Visual Studio
  10.0/VC/bin/cl.exe" is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: C:/Server Storage/Projects/- Personal Projects/0x10c/kernel/cmake/CMakeFiles/CMakeTmp

  Run Build Command:C:\PROGRA~2\MICROS~2.0\Common7\IDE\
  CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec159850540

  Microsoft (R) Visual Studio Version 10.0.40219.1.

  Copyright (C) Microsoft Corp. All rights reserved.

  1>------ Build started: Project: cmTryCompileExec159850540, Configuration:
  Debug Win32 ------

  1>C:\Program Files
  error MSB6001: Invalid command line switch for "CL.exe". Item has already
  been added. Key in dictionary: 'TMP' Key being added: 'tmp'

  ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):

-- Configuring incomplete, errors occurred!

C:\Server Storage\Projects\- Personal Projects\0x10c\kernel\cmake>
No tags attached.
zip (20,976) 2012-04-13 19:14
Issue History
2012-04-13 19:14JamesNew Issue
2012-04-13 19:14JamesFile Added:
2012-04-13 19:23JamesNote Added: 0029156
2012-04-16 09:22Brad KingNote Added: 0029173
2012-04-16 09:22Brad KingStatusnew => resolved
2012-04-16 09:22Brad KingResolutionopen => suspended
2012-04-16 09:22Brad KingAssigned To => Brad King
2012-04-16 09:22Brad KingAssigned ToBrad King =>
2012-04-20 19:43JamesNote Added: 0029288
2012-04-20 19:43JamesStatusresolved => feedback
2012-04-20 19:43JamesResolutionsuspended => reopened
2012-04-23 08:44Brad KingStatusfeedback => backlog
2012-04-23 08:44Brad KingResolutionreopened => open
2012-04-23 08:44Brad KingSummaryChecks for working C compiler (Visual Studio 2010) fail with any file => Windows CMake may not run safely at a Cygwin prompt
2012-04-23 08:46Brad KingNote Added: 0029306
2012-04-28 12:12Gehua yangNote Added: 0029360
2012-04-30 08:13Brad KingNote Added: 0029367
2012-05-09 14:15Bill HoffmanNote Added: 0029436
2012-05-17 16:24Gehua yangNote Added: 0029505
2012-05-18 05:37JamesNote Added: 0029506
2016-06-10 14:28Kitware RobotNote Added: 0042026
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

2012-04-13 19:23   
After this issue appeared in CMake, I am also no longer able to build projects in Visual Studio 2010 either! Now the C compiler under Visual Studio exits with the same error :(
Brad King   
2012-04-16 09:22   
CMake's installer does not modify the VS installation at all. I suspect something else corrupted your VS and CMake correctly reports that it is broken. You can try posting to the CMake user list [^]

to see if anyone else has encountered a similar problem.
2012-04-20 19:43   
I've narrowed this issue down to what follows:

If you try to use cmake -G from Cygwin and it needs to set up Visual Studio, the stricter casing mechanisms under Cygwin cause the environment variable names to conflict when they are re-added to the environment dictionary of the C compiler. Thus even when you try to set up the C compiler outside of Cygwin, it's broken. The only way to fix the problem is by restarting your computer and then doing the initial generation under the command prompt.

CMake should detect if it is running under Cygwin and refuse to do the initial set up of the C compiler, informing the user that they need to do the initial configuration under the command prompt.
Brad King   
2012-04-23 08:46   
Thanks for the additional details. That sounds hard to diagnose.

However, I cannot reproduce this:
$ uname

$ cmake --version
cmake version 2.8.7

$ cmake -G"Visual Studio 10" ..
-- Check for working C compiler using: Visual Studio 10
-- Check for working C compiler using: Visual Studio 10 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
Gehua yang   
2012-04-28 12:12   
I have encountered the same issue as James has described.

I am using same CMake version 2.8.7 and same Visual Studio 2010.

Cygwin version:
$ uname -a
CYGWIN_NT-6.1-WOW64 i7-vision 1.7.11(0.260/5/3) 2012-02-24 14:05 i686 Cygwin

 His report is accurate, in particular: 1) Issue only occurs when running CMake in Cygwin environment. 2) Once it occurs, even running CMake GUI or from command shell does not resolve the issue. 3) Once it occurs, it is persistent until computer reboot.
Brad King   
2012-04-30 08:13   
Re 0013131:0029288, 0013131:0029360: I have an identical version of Cygwin:

 $ uname -a
 CYGWIN_NT-6.1-WOW64 ... 1.7.11(0.260/5/3) 2012-02-24 14:05 i686 Cygwin

and cannot reproduce this. There must be something more to it.

Do you run as an administrative user or standard user?

What is in the PATH in Cygwin?

What is the exact command you enter at the Cygwin prompt?

What environment variable names conflict?
Bill Hoffman   
2012-05-09 14:15   
I reproduced this on my windows machine. I don't think there is anything cmake can do to fix the problem. However, I did discover some workarounds. The problem is that in the cygwin env it is defining mixed case env vars. For example:

$ env | grep -i tmp

If you run MSBuild from this environment it will not work. It does not matter what the name of the environment variable is, any mixed case env vars will cause MSBuild to die. One thing that makes this problem so hard to work with is that devenv launches MSBuild as a daemon process that stays running. This means that once an MSBuild gets started with a bad env, all future builds from devenv will get this error. So, workarounds:

1. unset all duplicate case env vars from the cygwin shell
2. Kill any running MSBuild processes that might have the bad env
3. Now run cmake to configure the project.

Another workaround, is to run the VS 10 IDE from the start menu, and build something, anything, so that it will start an MSBuild process. Then you can run cmake from the cygwin shell and it will work because the MSBuild process was not started with the bad env.

To me this looks like a bug in cygwin (they should not be creating dual case env vars), and a bug in MSBuild, it should not be a fatal error to get two copies of an env var with different case. I don't think either will be fixed, and there is not much cmake can do about this, as when it is run, it only sees the cygwin version of the env vars and can not detect the issue.
Gehua yang   
2012-05-17 16:24   
I confirm that "unset TMP" before running either CMake or devenv solves the problem.

Thank you all!
2012-05-18 05:37   
I think the appropriate course of action is for CMake to include a check for this situation when:

a) It's running under Cygwin (but not necessarily built under Cygwin!)
b) It has to do the initial compiler detection and
c) It would be detecting and probing Visual Studio 10

In this situation, CMake should refuse to continue and instead tell the user to perform the initial CMake command under the Windows Command Prompt.

(Cygwin can be detected at runtime simply by checking for the existence of /cygdrive).
Kitware Robot   
2016-06-10 14:28   
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.