View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015546CMakeCMakepublic2015-04-29 19:362016-01-04 11:51
ReporterSteven Petsche 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformWindows 7 x64OSWindowsOS Version7
Product VersionCMake 3.2.2 
Target VersionCMake 3.2.3Fixed in VersionCMake 3.2.3 
Summary0015546: Using MS or Intel compilers fails with MinGW Makefiles generator, worked with CMake 3.0.2
DescriptionCMake 3.0.2 was successfully used for a project. CMake 3.2.2 was installed to upgrade. Running CMake generator would fail in the startup because the Intel Fortran compiler would fail the ``try_compile'' hello world test after calling to enable Fortran. Output is below. The error message complained that there was *.dir/ -c/* in the path of the output pdb file. Since the wrong path seemed to be used, I investigated the rule used for this test compilation. It turns out that CMake/share/cmake-3.2/Modules/Platform/Windows-Intel.cmake uses Windows-MSVC.cmake to set up the CMAKE_Fortran_COMPILE_OBJECT variable for Intel Fortran on Windows. Line 261 of Windows-MSVC.cmake changed from 3.0.2 to 3.2.2. The compiler option ``/Fd<OBJECT_DIR>'' was replaced with ``/Fd<TARGET_COMPILE_PBD>''. Reverting this single line back to 3.0.2 or changing it to ``/Fd<TARGET_COMPILE_PDB>/'' solves the issue. The extra slash is needed by the Fortran compiler to know that it is a pdb directory and not a pdb filename being passed in. There seems to be confusion about whether a pdb filename or directory should be part of the compile rule. This may be an issue that TARGET_COMPILE_PDB can hold just a directory without the necessary trailing /. While it could be an easy fix, marked as major because you cannot enable Fortran with Intel Fortran on Windows without a difficult to find work around. CMake stops dead in its tracks. Interesting that the Windows Intel Fortran environment is set up just like the Microsoft environment (when Microsoft does not have Fortran).
Steps To ReproduceTry to enable Fortran when running CMake 3.2.2 from an Intel Fortran 2015 shell. Output is below.
Additional Information-- The Fortran compiler identification is Intel
-- Check for working Fortran compiler: C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe
-- Check for working Fortran compiler: C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe -- broken
CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.2/Modules/CMakeTestFortranCompiler.cmake:54 (message):
  The Fortran compiler "C:/Program Files (x86)/Intel/Composer XE
  2015/bin/intel64/ifort.exe" is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: C:/xxx/build/Release/build_fortran/CMakeFiles/CMakeTmp



  Run Build Command:"C:/MinGW/bin/mingw32-make.exe"
  "cmTryCompileExec143570813/fast"

  C:/MinGW/bin/mingw32-make.exe -f
  CMakeFiles\cmTryCompileExec143570813.dir\build.make
  CMakeFiles/cmTryCompileExec143570813.dir/build

  mingw32-make.exe[1]: Entering directory
  'C:/xxx/build/Release/build_fortran/CMakeFiles/CMakeTmp'

  "C:\Program Files (x86)\CMake\bin\cmake.exe" -E cmake_progress_report
  C:\xxx\build\Release\build_fortran\CMakeFiles\CMakeTmp\CMakeFiles 1

  Building Fortran object
  CMakeFiles/cmTryCompileExec143570813.dir/testFortranCompiler.f.obj

  C:\PROGRA~2\Intel\COMPOS~1\bin\intel64\ifort.exe /nologo /fpp /W1 /nologo
  /fpp /libs:dll /threads /debug:full /dbglibs
  /FoCMakeFiles\cmTryCompileExec143570813.dir\testFortranCompiler.f.obj
  /FdCMakeFiles\cmTryCompileExec143570813.dir\ -c
  C:\xxx\build\Release\build_fortran\CMakeFiles\CMakeTmp\testFortranCompiler.f


  error #31000: corrupt PDB file CMakeFiles\cmTryCompileExec143570813.dir
  -c\vc120.pdb; delete and rebuild; if problem persists, delete and try /Z7
  instead

  error code 3 ( can't write file, out of disk, etc.) opening pdb
  CMakeFiles\cmTryCompileExec143570813.dir -c\vc120.pdb

  compilation aborted for
  C:\xxx\build\Release\build_fortran\CMakeFiles\CMakeTmp\testFortranCompiler.f
  (code 1)

  CMakeFiles\cmTryCompileExec143570813.dir\build.make:56: recipe for target
  'CMakeFiles/cmTryCompileExec143570813.dir/testFortranCompiler.f.obj'
  failed

  mingw32-make.exe[1]: ***
  [CMakeFiles/cmTryCompileExec143570813.dir/testFortranCompiler.f.obj] Error
  1

  mingw32-make.exe[1]: Leaving directory
  'C:/xxx/build/Release/build_fortran/CMakeFiles/CMakeTmp'

  Makefile:116: recipe for target 'cmTryCompileExec143570813/fast' failed

  mingw32-make.exe: *** [cmTryCompileExec143570813/fast] Error 2
TagsNo tags attached.
Attached Filespatch file icon 0001-Makefile-Workaround-mingw32-make-trailing-backslash-.patch [^] (2,600 bytes) 2015-04-30 15:31 [Show Content]

 Relationships

  Notes
(0038657)
Brad King (manager)
2015-04-30 10:08

We have nightly testing of ifort on Windows and everything has been clean. I can't reproduce this problem either. With the "NMake Makefiles" generator the test project compilation command ends up as:

 "c:\Program Files (x86)\Intel\Composer XE 2015\bin\intel64\ifort.exe" /nologo /fpp /W1 /nologo /fpp /libs:dll /threads /debug:full /dbglibs /FoCMakeFiles\cmTryCompileExec1087262586.dir\testFortranCompiler.f.obj /FdCMakeFiles\cmTryCompileExec1087262586.dir\ -c "C:\...\CMakeFiles\CMakeTmp\testFortranCompiler.f"

and it works.

What CMake generator are you using?
(0038658)
Brad King (manager)
2015-04-30 10:13

I just tested with the "MinGW Makefiles" generator too. It also works.
(0038661)
Steven Petsche (reporter)
2015-04-30 12:18

CMake is called with -G"MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release

The output above confirms that mingw32-make was being used.

We run CMake from an Intel 2015 VS 2013 shell. This should be equivalent to opening cmd and running the command:
"C:\Program Files (x86)\Intel\Composer XE 2015\bin\ipsxe-comp-vars.bat" intel64 vs2013

Is this the same version Fortran compiler and environment setup? Should we be doing something different to set up the shell before calling CMake? The only other environment variables that are added before calling CMake are CXX=cl.exe and CC=cl.exe. Nothing else is defined for the Fortran env.

The output error above shows the same shell command that you posted without the quotes. However, the Fortran compilier is interpreting -c as part of the debug filename.

If I run 3.0.2 (which works) and check the CMakeOutput.log, the shell cmd it executed succuessfully was:

C:\PROGRA~2\Intel\COMPOS~1\bin\intel64\ifort.exe /nologo /fpp /W1 /nologo /fpp /libs:dll /threads /debug:full /dbglibs /FoCMakeFiles\cmTryCompileExec1388709765.dir\testFortranCompiler.f.obj /FdCMakeFiles\cmTryCompileExec1388709765.dir/ -c C:\apex\build\Release\build_fortran\CMakeFiles\CMakeTmp\testFortranCompiler.f

Note the debug directory ends with a / rather than a \ as in 3.2.2. I believe this is what is causing the issue. The ifort 2015 Windows manual (https://software.intel.com/en-us/node/525077 [^]) does not even document that a directory can be passed to the /Fd option, only a filename that can include a path (unlike the MSDN cl.exe documentation which explicitly says it needs a backslash for just a directory: https://msdn.microsoft.com/en-us/library/9wst99a9.aspx [^]). Obviously for ifort there must be some undocumented support for this option for it to ever work but ifort doesn't seem to like \ and needs / at the end instead to identify the directory. Based on this I will be really confused/stumped if you are using the same compiler version.

Based on both of our examples this means that <TARGET_COMPILE_PDB> does not expand to the same thing as <OBJECT_DIR> even though they were swapped out for each other from 3.0.2 to 3.2.2 (I haven't looked at versions in between so I don't know when the change actually happened). As an aside, based on the name I am surprised the new variable can hold just a directory.

PS: According to the Windows Fortran manual -c is not a documented option (also MSVC for that matter). It is /c for compile only on Windows, -c is for Linux. However, in 3.2.2, replacing -c with /c gives the expected command and error but now thinks c is a directory!:

  C:\PROGRA~2\Intel\COMPOS~1\bin\intel64\ifort.exe /nologo /fpp /W1 /nologo
  /fpp /libs:dll /threads /debug:full /dbglibs
  /FoCMakeFiles\cmTryCompileExec4043634529.dir\testFortranCompiler.f.obj
  /FdCMakeFiles\cmTryCompileExec4043634529.dir\ /c
  C:\xxx\build\Release\build_fortran\CMakeFiles\CMakeTmp\testFortranCompiler.f


  error #31000: corrupt PDB file CMakeFiles\cmTryCompileExec4043634529.dir
  \c\vc120.pdb; delete and rebuild; if problem persists, delete and try /Z7
  instead
(0038662)
Brad King (manager)
2015-04-30 13:37

For reference, the use of TARGET_COMPILE_PDB was added here:

 MSVC: Add properties to configure compiler PDB files
 http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ea3aee8 [^]

for issue 0014763. The passing of a directory to /Fd reproduces the behavior that the VS IDE uses when its build system invokes the compiler.

There is no difference between -c and /c as far as ifort or cl are concerned. Many MS-style tools interpret options with either "-" or "/" leading them.
(0038663)
Brad King (manager)
2015-04-30 13:40

Here is my cmd session:

 >"C:\Program Files (x86)\Intel\Composer XE 2015\bin\ipsxe-comp-vars.bat" intel64 vs2013
 >set PATH=%PATH%;c:\MinGW\bin
 >"c:\Program Files (x86)\CMake\bin\cmake.exe" --version
 cmake version 3.2.2
 >ifort
 Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 20140726
 >"c:\Program Files (x86)\CMake\bin\cmake.exe" ..\CMake\Tests\FortranOnly -G"MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release
 -- The Fortran compiler identification is Intel
 -- Check for working Fortran compiler: C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe
 -- Check for working Fortran compiler: C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe -- works
(0038664)
Brad King (manager)
2015-04-30 13:57

Based on your error message:

 corrupt PDB file CMakeFiles\cmTryCompileExec143570813.dir -c\vc120.pdb

generated from a command line containing

 /FdCMakeFiles\cmTryCompileExec143570813.dir\ -c

I think something must be interpreting the "\ " as an escaped space in your case, but not in mine even though we appear to have the same generated command line. Strange. The mingw32-make tool is supposed to still launch rules using "cmd" which does not interpret backslashes like that.
(0038665)
Steven Petsche (reporter)
2015-04-30 14:16

Very strange indeed. It seems that mingw32-make is the only thing that we have not yet confirmed in the same version (assuming you are using Windows 7). Can you check your version? I'll be happy to upgrade if that is causing the problem. I'm running out of ideas on what could be causing this misinterpretation of the \.

Just for completeness here is my cmd session (omitting the rest of the same error message as above) for an otherwise empty directory ``test'' with a CMakeLists.txt containing:

cmake_minimum_required(VERSION 3.2.2)
cmake_policy(VERSION 3.2.2)
project(test LANGUAGES NONE)
enable_language(Fortran)

Standard cmd session:
C:\test>"C:\Program Files (x86)\Intel\Composer XE 2015\bin\ipsxe-comp-vars.bat" intel64 vs2013
Intel(R) Parallel Studio XE 2015
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.
Intel(R) Parallel Studio XE 2015 Composer Edition (package 108)

C:\test>cmake --version
cmake version 3.2.2

C:\test>ifort
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 20140726
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.

C:\test>mingw32-make -v
GNU Make 3.82.90
Built for i686-pc-mingw32
Copyright (C) 1988-2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> [^]
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

C:\test>cmake -G"MinGW Makefiles"
-- The Fortran compiler identification is Intel
-- Check for working Fortran compiler: C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe
-- Check for working Fortran compiler: C:/Program Files (x86)/Intel/Composer XE 2015/bin/intel64/ifort.exe -- broken
CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.2/Modules/CMakeTestFortranCompiler.cmake:54 (message):
  The Fortran compiler "C:/Program Files (x86)/Intel/Composer XE
  2015/bin/intel64/ifort.exe" is not able to compile a simple test program.
(0038666)
Brad King (manager)
2015-04-30 14:57

>mingw32-make --version
GNU Make 3.82.90

I noticed from your session that your build tree has no space in its path. All my testing was done with a space in the path (which almost always is harder than without, so I develop that way).

I am able to reproduce this when I build with no space in the path to my build tree. It makes a difference because I observe the following behavior from mingw32-make. I wrote a tiny "args" program that just prints out the arguments it receives. With this makefile:

all:
    args a\ b c


it prints "a b" and "c" as the arguments. With this makefile:

all:
    args a\ b "c"


it prints "a\", "b", and "c" as the arguments as expected.

So, mingw32-make has different behavior based on quotes in different arguments!?
(0038667)
Brad King (manager)
2015-04-30 15:20

FYI, in the code:

 cmake_minimum_required(VERSION 3.2.2)
 cmake_policy(VERSION 3.2.2)

the cmake_policy call is redundant. cmake_minimum_required(VERSION) is documented to imply an equivalent cmake_policy(VERSION).
(0038668)
Brad King (manager)
2015-04-30 15:24

I'm also able to reproduce this for enabling "C" with the MS "cl" compiler. mingw32-make causes the same problem there.
(0038669)
Brad King (manager)
2015-04-30 15:31

The attached 0001-Makefile-Workaround-mingw32-make-trailing-backslash-.patch should fix this.
(0038670)
Steven Petsche (reporter)
2015-04-30 16:22

Great catch. Thanks for giving me the benefit of the doubt and working to reproduce this bug. Thanks for the patch and cmake_policy advice. Our project had only ``cmake_minimum_required(VERSION 3.0.2)'' which with 3.2.2 emitted a Policy CMP0054 warning that suggested using cmake_policy so I added it at the same time I changed the required version to 3.2.2. Now I understand that changing the required to 3.2.2 was all I needed to do.
(0038673)
Brad King (manager)
2015-05-01 08:24

I've committed the patch here:

 Makefile: Workaround mingw32-make trailing backslash trouble
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb6663ca [^]
(0038674)
Brad King (manager)
2015-05-01 08:26

Re 0015546:0038670: FYI, you can use if(POLICY) and cmake_policy(SET ...) to set policies for newer CMake versions without updating cmake_minimum_required to them. Also in the case of CMP0054 it is likely possible to edit your code to not hit the case at all. Of course if you want to require 3.2.2 I won't stop you ;)
(0040057)
Robert Maynard (manager)
2016-01-04 11:51

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2015-04-29 19:36 Steven Petsche New Issue
2015-04-30 10:08 Brad King Note Added: 0038657
2015-04-30 10:13 Brad King Note Added: 0038658
2015-04-30 12:18 Steven Petsche Note Added: 0038661
2015-04-30 13:37 Brad King Note Added: 0038662
2015-04-30 13:40 Brad King Note Added: 0038663
2015-04-30 13:57 Brad King Note Added: 0038664
2015-04-30 14:16 Steven Petsche Note Added: 0038665
2015-04-30 14:57 Brad King Note Added: 0038666
2015-04-30 15:20 Brad King Note Added: 0038667
2015-04-30 15:24 Brad King Note Added: 0038668
2015-04-30 15:24 Brad King Assigned To => Brad King
2015-04-30 15:24 Brad King Status new => assigned
2015-04-30 15:24 Brad King Target Version => CMake 3.3
2015-04-30 15:24 Brad King Summary Enabling Fortran with the Intel Fortran compiler fails, worked with 3.0.2 => Using MS or Intel compilers fails with MinGW Makefiles generator, worked with CMake 3.0.2
2015-04-30 15:31 Brad King File Added: 0001-Makefile-Workaround-mingw32-make-trailing-backslash-.patch
2015-04-30 15:31 Brad King Note Added: 0038669
2015-04-30 16:22 Steven Petsche Note Added: 0038670
2015-05-01 08:24 Brad King Note Added: 0038673
2015-05-01 08:24 Brad King Status assigned => resolved
2015-05-01 08:24 Brad King Resolution open => fixed
2015-05-01 08:24 Brad King Fixed in Version => CMake 3.3
2015-05-01 08:26 Brad King Note Added: 0038674
2015-06-01 14:48 Brad King Fixed in Version CMake 3.3 => CMake 3.2.3
2015-06-01 14:48 Brad King Target Version CMake 3.3 => CMake 3.2.3
2016-01-04 11:51 Robert Maynard Note Added: 0040057
2016-01-04 11:51 Robert Maynard Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team