View Issue Details Jump to Notes ] Print ]
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)
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
Attached Filesdiff file icon mingw64.diff [^] (10,118 bytes) 2010-02-27 05:58 [Show Content]
diff file icon cmake-mingw64.diff [^] (11,754 bytes) 2010-02-27 14:45 [Show Content]

 Relationships

  Notes
(0019654)
rubenvb (reporter)
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 (manager)
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 (reporter)
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 (reporter)
2010-02-27 18:25

The right patch is named "cmake-mingw64.diff". The other is ... a mistake on my end.
(0019781)
rubenvb (reporter)
2010-03-09 15:48

What's the status on this? Did you already have a chance to try compilation?
(0019838)
Bill Hoffman (manager)
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 (reporter)
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 (developer)
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 (manager)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
2010-03-20 04:50

Have you gotten any further on this issue? Thanks
(0019969)
Bill Hoffman (manager)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (manager)
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 (reporter)
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 (reporter)
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 (manager)
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 (reporter)
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 (reporter)
2010-04-18 10:41

How does the new merge request look? CMake still builds cleanly. Thanks!
(0020386)
rubenvb (reporter)
2010-04-24 04:57

Have you had a chance to review my patch/merge request? Thanks
(0020604)
Bill Hoffman (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (reporter)
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 (reporter)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2010-02-27 05:58 rubenvb New Issue
2010-02-27 05:58 rubenvb File Added: mingw64.diff
2010-02-27 05:59 rubenvb Tag Attached: mingw
2010-02-27 05:59 rubenvb Tag Attached: mingw-w64
2010-02-27 05:59 rubenvb Tag Attached: mingw64
2010-02-27 06:14 rubenvb Note Added: 0019654
2010-02-27 10:29 Bill Hoffman Note Added: 0019655
2010-02-27 10:29 Bill Hoffman Status new => assigned
2010-02-27 10:29 Bill Hoffman Assigned To => Bill Hoffman
2010-02-27 12:04 rubenvb Note Added: 0019656
2010-02-27 12:06 rubenvb Note Edited: 0019656
2010-02-27 14:45 rubenvb File Added: cmake-mingw64.diff
2010-02-27 18:25 rubenvb Note Added: 0019659
2010-03-09 15:48 rubenvb Note Added: 0019781
2010-03-11 08:16 Bill Hoffman Note Added: 0019838
2010-03-11 14:34 rubenvb Note Added: 0019844
2010-03-11 17:29 David Partyka Note Added: 0019849
2010-03-12 11:21 Bill Hoffman Note Added: 0019857
2010-03-13 07:17 rubenvb Note Added: 0019863
2010-03-13 07:30 rubenvb Note Added: 0019864
2010-03-13 07:41 rubenvb Note Added: 0019865
2010-03-20 04:50 rubenvb Note Added: 0019968
2010-03-20 16:04 Bill Hoffman Note Added: 0019969
2010-03-20 17:53 rubenvb Note Added: 0019970
2010-03-27 14:00 rubenvb Note Added: 0020020
2010-03-27 14:33 rubenvb Note Added: 0020021
2010-04-01 12:50 rubenvb Note Added: 0020050
2010-04-01 12:58 Bill Hoffman Note Added: 0020051
2010-04-01 14:54 rubenvb Note Added: 0020052
2010-04-12 14:38 rubenvb Note Added: 0020139
2010-04-12 14:56 Bill Hoffman Note Added: 0020140
2010-04-12 16:21 rubenvb Note Added: 0020143
2010-04-18 10:41 rubenvb Note Added: 0020246
2010-04-24 04:57 rubenvb Note Added: 0020386
2010-05-05 17:16 Bill Hoffman Note Added: 0020604
2010-05-06 13:19 rubenvb Note Added: 0020621
2010-05-06 14:16 Bill Hoffman Note Added: 0020622
2010-05-06 15:16 rubenvb Note Added: 0020628
2010-10-21 12:29 Adam J Richardson #2 Note Added: 0022597
2010-10-22 13:33 rubenvb Note Added: 0022662
2016-06-10 14:27 Kitware Robot Note Added: 0041659
2016-06-10 14:27 Kitware Robot Status assigned => resolved
2016-06-10 14:27 Kitware Robot Resolution open => moved
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team