MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010344CMakeCMakepublic2010-02-27 05:582016-06-10 14:31
Reporterrubenvb 
Assigned ToBill Hoffman 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0010344: Windows CMake compilation under mingw-w64
DescriptionWhen building CMake under Windows using a binary CMake 2.8.0 release and using a mingw-w64 toolchain, compilation fails because the Windows reserved keyword BOOL is used as a property name. Also, an #ifdef structure does not check for mingw, so it does not define a critical function.

These are all trivial patches (renaming 1 variable in +/- 11 files), and adding a conditional for mingw(-w64)
Steps To Reproduce
Additional InformationTwo tests fail currently, Fortran and SubDirSpaces. Will look into it.

Attached is the patch with the required changes to cmake and QtDialog.
Tagsmingw, mingw-w64, mingw64
Relationships
Attached Filesdiff mingw64.diff (10,118) 2010-02-27 05:58
https://public.kitware.com/Bug/file/2909/mingw64.diff
diff cmake-mingw64.diff (11,754) 2010-02-27 14:45
https://public.kitware.com/Bug/file/2912/cmake-mingw64.diff
Issue History
Date ModifiedUsernameFieldChange
2010-02-27 05:58rubenvbNew Issue
2010-02-27 05:58rubenvbFile Added: mingw64.diff
2010-02-27 05:59rubenvbTag Attached: mingw
2010-02-27 05:59rubenvbTag Attached: mingw-w64
2010-02-27 05:59rubenvbTag Attached: mingw64
2010-02-27 06:14rubenvbNote Added: 0019654
2010-02-27 10:29Bill HoffmanNote Added: 0019655
2010-02-27 10:29Bill HoffmanStatusnew => assigned
2010-02-27 10:29Bill HoffmanAssigned To => Bill Hoffman
2010-02-27 12:04rubenvbNote Added: 0019656
2010-02-27 12:06rubenvbNote Edited: 0019656
2010-02-27 14:45rubenvbFile Added: cmake-mingw64.diff
2010-02-27 18:25rubenvbNote Added: 0019659
2010-03-09 15:48rubenvbNote Added: 0019781
2010-03-11 08:16Bill HoffmanNote Added: 0019838
2010-03-11 14:34rubenvbNote Added: 0019844
2010-03-11 17:29David PartykaNote Added: 0019849
2010-03-12 11:21Bill HoffmanNote Added: 0019857
2010-03-13 07:17rubenvbNote Added: 0019863
2010-03-13 07:30rubenvbNote Added: 0019864
2010-03-13 07:41rubenvbNote Added: 0019865
2010-03-20 04:50rubenvbNote Added: 0019968
2010-03-20 16:04Bill HoffmanNote Added: 0019969
2010-03-20 17:53rubenvbNote Added: 0019970
2010-03-27 14:00rubenvbNote Added: 0020020
2010-03-27 14:33rubenvbNote Added: 0020021
2010-04-01 12:50rubenvbNote Added: 0020050
2010-04-01 12:58Bill HoffmanNote Added: 0020051
2010-04-01 14:54rubenvbNote Added: 0020052
2010-04-12 14:38rubenvbNote Added: 0020139
2010-04-12 14:56Bill HoffmanNote Added: 0020140
2010-04-12 16:21rubenvbNote Added: 0020143
2010-04-18 10:41rubenvbNote Added: 0020246
2010-04-24 04:57rubenvbNote Added: 0020386
2010-05-05 17:16Bill HoffmanNote Added: 0020604
2010-05-06 13:19rubenvbNote Added: 0020621
2010-05-06 14:16Bill HoffmanNote Added: 0020622
2010-05-06 15:16rubenvbNote Added: 0020628
2010-10-21 12:29Adam J Richardson #2Note Added: 0022597
2010-10-22 13:33rubenvbNote Added: 0022662
2016-06-10 14:27Kitware RobotNote Added: 0041659
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0019654)
rubenvb   
2010-02-27 06:14   
Using another build of the make utility lets SubDirSpaces complete without a hitch. The Fortran test is being looked into, it is a fortran code bug somewhere and is not crucial for any other language/project cmake supports and thus not a blocker for the proposed fix.
(0019655)
Bill Hoffman   
2010-02-27 10:29   
"Windows reserved keyword BOOL is used as a property name"

We build on windows all the time?? We have never had trouble with BOOL, what is mingw 64 doing that mingw and MSVC are not? I will try a copy mingw64 on Monday.
(0019656)
rubenvb   
2010-02-27 12:04   
(edited on: 2010-02-27 12:06)
Remember to use sezero's builds (they work the best, at least for me)
link: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_20100223/ [^]

And for the SubDirSpaces test to pass, you will need to use this make:
https://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/make/make-3.81-20100227.zip/download [^]
(0019659)
rubenvb   
2010-02-27 18:25   
The right patch is named "cmake-mingw64.diff". The other is ... a mistake on my end.
(0019781)
rubenvb   
2010-03-09 15:48   
What's the status on this? Did you already have a chance to try compilation?
(0019838)
Bill Hoffman   
2010-03-11 08:16   
We are unable to use this tool set... Can you describe how you installed it and ran cmake with the tool set?
(0019844)
rubenvb   
2010-03-11 14:34   
for windows:
Download http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_20100306/mingw-w64-bin_i686-mingw_20100306_sezero.zip/download [^]
and unzip to for example c:\mingw64 so that this folder contains bin, lib and so forth.
install cmake to eg c:\cmake
unzip cmake sources to c:\cmake-src
open cmd.exe
run:
set PATH=c:\cmake\bin;c:\mingw64\bin;%PATH%
mkdir c:\cmake-build
cd c:\cmake-build
cmake c:\cmake-src -G"MinGW Makefiles"
gmake -j3
----
That's it
cmake c:\cmake-src
(0019849)
David Partyka   
2010-03-11 17:29   
When I try this I get: Is there something else I should be installing/setting?

c:\Kitware\CMake\binMinGWx64>cmake ..\src.git -G"MinGW Makefiles"
CMake Error: CMake was unable to find a build program corresponding to "MinGW Ma
kefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a differe
nt build tool.
CMake Error: CMake was unable to find a build program corresponding to "MinGW Ma
kefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a differe
nt build tool.
CMake Error: Error required internal CMake variable not set, cmake may be not be
 built correctly.
Missing variable is:
CMAKE_C_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not be
 built correctly.
Missing variable is:
CMAKE_C_COMPILER
CMake Error: Could not find cmake module file:C:/Kitware/CMake/binMinGWx64/CMake
Files/CMakeCCompiler.cmake
CMake Error: Error required internal CMake variable not set, cmake may be not be
 built correctly.
Missing variable is:
CMAKE_CXX_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not be
 built correctly.
Missing variable is:
CMAKE_CXX_COMPILER
CMake Error: Could not find cmake module file:C:/Kitware/CMake/binMinGWx64/CMake
Files/CMakeCXXCompiler.cmake
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
(0019857)
Bill Hoffman   
2010-03-12 11:21   
The problem is that CMake looks here:
FIND_PROGRAM(CMAKE_MAKE_PROGRAM mingw32-make.exe PATHS
  "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\
\MinGW;InstallLocation]/bin"
  c:/MinGW/bin /MinGW/bin)

The 64bit one is not found, it seems to be just called gmake.exe. How did you get this to work?
(0019863)
rubenvb   
2010-03-13 07:17   
If it's looking for mingw32-make, just rename mingw64\bin\gmake.exe to mingw32-make.exe. The mingw-w64 team uses a different name for their make program, which leads to this kind of behavior (Qt for example also needs a mingw32-make.exe). This is done to keep mingw.org and mingw-w64 distinguishable I presume.

Sorry I forgot about that, it's something I do automatically, just copy or rename the gmake.exe to mingw32-make.exe or download it seperately from:
http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/make/make_20100202_bin.zip/download [^]
But this also needs to be renamed to mingw32-make.exe for cmake to find it.
(0019864)
rubenvb   
2010-03-13 07:30   
Forgot to mention: for the subdrispaces test to pass, you will need the external gmake.exe, there is a bug in make SVN (included in the mingw64 package) that causes it to fail.
(0019865)
rubenvb   
2010-03-13 07:41   
Correction:
 - make is versioned in CVS, not SVN :)
 - the linked make build does not fix the SubDirSpaces problem, a bug report has been submitted to make devs.
(0019968)
rubenvb   
2010-03-20 04:50   
Have you gotten any further on this issue? Thanks
(0019969)
Bill Hoffman   
2010-03-20 16:04   
No, we can not build at all??? Even if we tell CMake the make program or rename it it has all sorts of basic not working issues. We need more detailed install instructions.
(0019970)
rubenvb   
2010-03-20 17:53   
Ok, sorry for the trouble. Here's me going into full detail:

-OS: Windows 7 x64 Ultimate
-CMake (binary release 2.8.1): M:\Development\cmake\bin\cmake.exe
-CMake sources (2.8.1 zip): M:\Development\x64\cmake
-mingw64 (64-bit Windows): http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_20100313/mingw-w64-bin_x86_64-mingw_20100313_sezero.zip/download [^]
-mingw64 (32-bit Windows): http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_20100313/mingw-w64-bin_i686-mingw_20100313_sezero.zip/download [^]
-extract mingw64 to M:\Development\
-gcc.exe location is: M:\Development\mingw64\bin\gcc.exe
-rename gmake.exe to mingw32-make.exe located in M:\Development\mingw64\mingw32-make.exe
-open cmd.exe and execute these commands:
set PATH=M:\Development\cmake\bin;M:\Development\ming64\bin
M:
cd Development\x64\cmake
mkdir build
cd build
cmake .. -G"MinGW Makefiles"
gmake (or mingw32-make, whatever suits you)

More detail than this is pretty much impossible. I hope it works for you (I just executed this and it works here)
(0020020)
rubenvb   
2010-03-27 14:00   
Can you please provide more detail on your problems, because they are not normal and I do not experience them. The proposed change is minor, and would mean mingw(-w64/w32) can build and use CMake without a problem. I'd love to help.
Your previous errors:
 - CMAKE_MAKE_PROGRAM not set: rename gmake to mingw32-make
 - be sure to set PATH to the mingw64/bin folder so that the toolchain can be found

PS: On a side note, I'm quite sure the automatic builds (vs sezero's personal builds) will not have the Fortran test failure.
(0020021)
rubenvb   
2010-03-27 14:33   
FYI: I have just built the current git version (tree=d205aeac6bc15e6f850cf26cc8e22f6f8b7b702a) and found that it needs one small fix, on top of the BOOL<->CBOOL replacements in the attaches cmake-mingw64.patch:

In Utilities/cmlibarchive/libarchive/archive_windows.h: line 303 needs to be surrounded by a #if defined(_MSVC_VER)...#endif because MinGW(-w64/w32) already have pid_t.
(0020050)
rubenvb   
2010-04-01 12:50   
I have made a git merge request pertaining the issue:

http://gitorious.org/cmake/cmake/merge_requests/1 [^]

The BOOL naming issue has been solved on mingw-w64 side, all that remains is the pid_t problem and a 64 to 32-bit pointer cast fix (see merge request).
(0020051)
Bill Hoffman   
2010-04-01 12:58   
The new patch looks much better... :) The BOOL thing seemed like a mingw bug to me... Do you have to update to a new mingw64 build for this?
(0020052)
rubenvb   
2010-04-01 14:54   
Yeah, for now the file is in svn, see

http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/branches/releases/v1.0/mingw-w64-headers/include/windef.h?revision=2127&pathrev=2127 [^]

Copy this into mingw64/x86_64-w64-mingw32/include/

Latest sezero toolchain build is 20100327. Don't forget the rename of gmake->mingw32-make, or otherwise CMake refuses to continue and quits with a "CMAKE_MAKE_PROGRAM is not set." error. You may always add gmake.exe to the search for CMAKE_MAKE_PROGRAM of course :)
(0020139)
rubenvb   
2010-04-12 14:38   
Hi, I'm trying to build a fresh git CMake, but am running into some problems in cmlibarchive: the cmake generated config.h conflicts with Utilities/cmlibarchive/libarchive/config_windows.h:
 - gid_t redefined (in config_windows.h, previously defined in config.h)
 - id_t redefined (idem)
 - uid_t redefined (idem)

Which result in conflicting types for several functions in archive_entry.c. What should be done? Which *config.h is the right one? Thanks
(0020140)
Bill Hoffman   
2010-04-12 14:56   
This seems to be a problem caused by your patch. I tried your git clone and was not able to build with visual studio, lots of errors like this:
1>Compiling...
1>archive_check_magic.c
1>c:\hoffman\projects\cmakefix\utilities\cmlibarchive\libarchive\archive_windows.h(381) : error C2061: syntax error : identifier '__la_waitpid'
1>c:\hoffman\projects\cmakefix\utilities\cmlibarchive\libarchive\archive_windows.h(381) : error C2059: syntax error : ';'
1>c:\hoffman\projects\cmakefix\utilities\cmlibarchive\libarchive\archive_windows.h(381) : error C2146: syntax error : missing ')' before identifier 'wpid'
1>c:\hoffman\projects\cmakefix\utilities\cmlibarchive\libarchive\archive_windows.h(381) : error C2061: syntax error : identifier 'wpid'
1>c:\hoffman\projects\cmakefix\utilities\cmlibarchive\libarchive\archive_windows.h(381) : error C2059: syntax error : ','
1>c:\hoffman\projects\cmakefix\utilities\cmlibarchive\libarchive\archive_windows.h(381) : error C2059: syntax error : ')'

With the official repo: git clone git://cmake.org/cmake.git [^] CMake

These errors do not happen...
(0020143)
rubenvb   
2010-04-12 16:21   
Wow, stupid typo alert: it's _MSC_VER, not _MSVC_VER. Will be fixed in an updated merge request when I get through a full build (this time also with MSVC x64).

...Build complete. Updated merge request! Apologies for the typo :)
(0020246)
rubenvb   
2010-04-18 10:41   
How does the new merge request look? CMake still builds cleanly. Thanks!
(0020386)
rubenvb   
2010-04-24 04:57   
Have you had a chance to review my patch/merge request? Thanks
(0020604)
Bill Hoffman   
2010-05-05 17:16   
I have merged your changes into git master. Thanks. BTW, can you run a mingw64 dashboard for CMake?
(0020621)
rubenvb   
2010-05-06 13:19   
I'm not sure what you mean. Do you mean a git branch/repo with up to date patches for mingw64?
(0020622)
Bill Hoffman   
2010-05-06 14:16   
git master in the main CMake git now has your changes in it. Please try.

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7883f952b06e378eef7662a42a8c466cbe5aa285 [^]

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7883f952b06e378eef7662a42a8c466cbe5aa285 [^]
(0020628)
rubenvb   
2010-05-06 15:16   
Hi,

build: succesful (did not test Qt gui as it needs static build which i don't have currently)
test: 3 failed, of which 2 expected:
subdirspaces (expected): gnu make bug
ctestteststoptime: don't know why
fortran (expected): gfortran issue with mingw64

Thanks for applying the patch!
(0022597)
Adam J Richardson #2   
2010-10-21 12:29   
I think there's still some confusion here. BOOL is a typedef in stock MS libraries. This is of course cloned in MinGW's w32api, which is what Ruben refers to. If it's a MinGW bug, it was a Windows bug first.

Would I be right in assuming the Win32 build of CMake doesn't use w32api much, if at all?

In the w32api version of windef.h, BOOL is typedef'd to WINBOOL and WINBOOL is typedef'd to int.

Raymond Chen discusses BOOL here:
http://blogs.msdn.com/b/oldnewthing/archive/2004/12/22/329884.aspx [^]

Ruben, did you #include "windows.h" to get CMake building? That would explain the conflict.

Great idea to compile CMake for 64-bit, I must try that on my MinGW-w64. ;)
(0022662)
rubenvb   
2010-10-22 13:33   
There's no confusion: there is special objective-c(++) magic in the mingw-w64 headers, which messed with the correct definition of (WIN)BOOL in certain situations like this one. The issue has been fixed and CMake (last time I checked) built succesfully with mingw-w64.

Only some test failures, which is actually the only reason this report is still open (if I or someone else gets the time or will to do something about them).

Probably the only one that needs fixing is the cteststoptime. Subdirspaces is a mingw32-make bug and fortran is probably a bug in my mingw-w64 build. Thanks for the interest though.
(0041659)
Kitware Robot   
2016-06-10 14:27   
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.