View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0010344 | CMake | CMake | public | 2010-02-27 05:58 | 2016-06-10 14:31 | ||||
Reporter | rubenvb | ||||||||
Assigned To | Bill Hoffman | ||||||||
Priority | normal | Severity | feature | Reproducibility | always | ||||
Status | closed | Resolution | moved | ||||||
Platform | OS | OS Version | |||||||
Product Version | CMake-2-8 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0010344: Windows CMake compilation under mingw-w64 | ||||||||
Description | When 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 Information | Two tests fail currently, Fortran and SubDirSpaces. Will look into it. Attached is the patch with the required changes to cmake and QtDialog. | ||||||||
Tags | mingw, mingw-w64, mingw64 | ||||||||
Attached Files | mingw64.diff [^] (10,118 bytes) 2010-02-27 05:58 [Show Content]
cmake-mingw64.diff [^] (11,754 bytes) 2010-02-27 14:45 [Show Content] | ||||||||
Relationships | |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |