CMake fails to generate MinGW Makefiles for latest SFML master on Win 7 64-bit

[Ixrec]

A few minutes ago, I checked out the latest SFML from github using TortoiseGit, I downloaded and installed cmake-3.0.2-win32-x86.exe from http://www.cmake.org/download/, and I downloaded and installed MinGW Builds from http://sourceforge.net/projects/mingwbuilds/.  After I gave CMake source and build paths, and told it to use CodeBlocks - MinGW Makefiles (or just plain MinGW Makefiles), it fails with the following error:

CMake Error at cmake/Config.cmake:16 (message):
  Unsupported architecture
Call Stack (most recent call first):
  CMakeLists.txt:20 (include)

I'm currently running a Dell Latitude 3540 with Windows 7 Professional 64-bit.  Inspecting the cmake/Config.cmake implies that CMake and/or MinGW is under the impression that my architecture is neither 32-bit nor 64-bit.  I don't have the slightest idea how that could be possible unless one or the other is simply broken (since I've had no trouble with CMake in the past, and I've never ever gotten MinGW to work before, I'm highly inclined to assume the latter is broken somehow).

Note that I also installed CodeBlocks earlier so its version of MinGW may be interfering somehow.  I was going to try specifying native compilers myself in CMake but I can't seem to find where either set of actual compilers was installed (I really hate it when software feels the need to hide itself...)

Searching this forum got me one or two hits that appeared to be completely different problems, and the workaround described in one didn't come close to working so I don't think those are relevant.

Any ideas?


Edit: Found the MinGW binaries that came with CodeBlocks.  Specifying them in CMake did not change the error, so maybe these are the broken ones.  But I still can't find the MinGW Builds binaries so I can't test those.

Edit: The MinGW Builds installer emits an error dialogue containing the text "ERROR res", and then proceeds to finish and claim it installed successfully (hence I forgot about this earlier).  Googling this error got me nothing.

[eXpl0it3r]

I've just updated my CMake to the latest version and as you, I'm using the MinGW Builds, I've tested both Posix Dwarf 4.9.1r1 x86 and Posix SEH 4.9.1r1 x64 and everything built fine.

So you're saying the CMake config script detects your system as Windows, right?
But then fails at the architecture detection?

Could you print out in CMake what ${SIZEOF_VOID_PTR} returns?

[Ixrec]

So you're saying the CMake config script detects your system as Windows, right?
But then fails at the architecture detection?

I'm guessing that's what's happening based on the error message it produced.

Could you print out in CMake what ${SIZEOF_VOID_PTR} returns?

How do I do that?  The only other piece of output in the cmake-gui console that looks relevant is this:
Check size of void*
Check size of void* - failed

Edit: Modfying the cmake files to print out the value just prints a blank, and given that "Check size of void* - failed" message maybe the variable never actually gets a value.

Again, googling this gets nothing useful; just a few other project maintainers saying "well that should work" and others saying "turns out my install of _ was broken".

Edit: Just tried downloading, installing and specifying a previous version of MinGW Builds (x64-4.7.3-release-win32-sjlj-rev1.7z to be precise) and got the exact same error.

[eXpl0it3r]

Well mentioning that message might have been important.

The architecture is detected by checking the size of the void pointer, since that seems to fail (for whatever reason), then as the Google results say, your installation has to be broken.

At best you go, fully uninstall CMake, then reinstall. Try again.
If it still fails, also download a new compiler (e.g. this one), clear your PATH variable, so it doesn't accidentally contain multiple MinGW or CMake versions and try again.

After that, I'm quite out of options. Maybe you could try the older CMake version again?

[Ixrec]

Well mentioning that message might have been important.

I didn't see it before because cmake-gui decided to scroll down just enough to hide it and only show the red bits I originally mentioned.  Go figure.


Uninstalling and reinstalling the same version of CMake did nothing.

Installing and specifying the version of MinGW that you linked failed when I clicked Configure with a series of "cc1.exe - System Error" saying that "libwinpthread-1.dll" is missing.

I've been periodically checking my windows PATH and at no point did it have any instances of "mingw" or "cmake".

Gonna try an older version of CMake now and see if it accepts any of the versions of MinGW I have now.

[Ixrec]

CMake 2.8.12.2 give me all of the same errors on all of the previously tried versions of MinGW.


So the version of MinGW that you linked is missing a key dll, the MinGW Builds version can't even install itself, and a manual install of MinGW Builds or the CodeBlocks version of MinGW both fail at the void* size check.  And all of the above are true in multiple CMake versions.

As a last ditch effort I'm going to install a zillion cygwin packages and see if its version of MinGW fares any better.

[Ixrec]

Decided to try clang while I was at it.  CMake doesn't seem to know that Clang exists because every generator I can think of specifying gets "unable to find a build program corresponding to" despite the fact that I'm pointing it right at the Clang binaries.  Has anyone ever built SFML with Clang?

And in all seriousness, how is it even possible for so many combinations of MinGW builds and CMake versions to be so thoroughly broken and unusable on my machine when you appear to have no difficulty whatsoever?  I've reinstalled all of the above multiple times just in the past hour, so there's no way anything could be out of date.

[eXpl0it3r]

The winpthread DLL can be found like the rest of the DLL and EXEs in the bin directory.
Since you say there's no MinGW version in PATH, how do you start CMake then?
If that DLL can't be found, then you seem to be doing something wrong.

Here's what I do, since I still have 6 different MinGW compilers "installed".

• Have CMake in PATH (only on version of course).
• Open a new CMD
• Enter something along the line of: set PATH=C:\Dev\MinGW32-PosixDwarf491r1\bin;%PATH%
• Enter cmake-gui to open CMake with the right PATH variable set.
• Set all the variables etc and so forth.
• cd to the build directory
• Enter mingw32-make install -j8

The curcial part is here, that PATH isn't "contaminated" by some odd MinGW install, that I specify which compiler I want to use by manually adding it to PATH and by launching CMake through the CMD, which will automatically serve the right PATH variables. If you start CMake via Explorer it will still use the system wide set PATH variables.

I can't recommend cygwin.

[eXpl0it3r]

Well you were faster

Decided to try clang while I was at it.  CMake doesn't seem to know that Clang exists because every generator I can think of specifying gets "unable to find a build program corresponding to" despite the fact that I'm pointing it right at the Clang binaries.  Has anyone ever built SFML with Clang?

How/from where did you get Clang?

And in all seriousness, how is it even possible for so many combinations of MinGW builds and CMake versions to be so thoroughly broken and unusable on my machine when you appear to have no difficulty whatsoever?  I've reinstalled all of the above multiple times just in the past hour, so there's no way anything could be out of date.

They are not broken, it's just that something in your configuration is screwed up. Always try to find the errors on your side first.

[Ixrec]

Decided to try clang while I was at it.  CMake doesn't seem to know that Clang exists because every generator I can think of specifying gets "unable to find a build program corresponding to" despite the fact that I'm pointing it right at the Clang binaries.  Has anyone ever built SFML with Clang?

How/from where did you get Clang?

http://llvm.org/releases/download.html

And in all seriousness, how is it even possible for so many combinations of MinGW builds and CMake versions to be so thoroughly broken and unusable on my machine when you appear to have no difficulty whatsoever?  I've reinstalled all of the above multiple times just in the past hour, so there's no way anything could be out of date.

They are not broken, it's just that something in your configuration is screwed up. Always try to find the errors on your side first.

What do you think I was doing in the last several posts?

Since you say there's no MinGW version in PATH, how do you start CMake then?

By clicking on it in the start menu.  I left everything on default during the installation, and "don't add CMake to PATH" was one of the default options in its installer.



Incidentally, I can't seem to run any of the MinGWs or Clang from a terminal window either.  In both Cygin and cmd they all fail in various ways: one gives me the aforementioned dll error, one literally does nothing, one claims it can't find the iostream header, and a few claim "cannot open output file" even when explicitly give it my home folder as the output directory.

Is it a bad idea to install any dev tools in Program Files?  Should I move everything to a C:/Dev/ folder too where permission problems won't be an issue?

The winpthread DLL can be found like the rest of the DLL and EXEs in the bin directory.
Since you say there's no MinGW version in PATH, how do you start CMake then?
If that DLL can't be found, then you seem to be doing something wrong.

Here's what I do, since I still have 6 different MinGW compilers "installed".

• Have CMake in PATH (only on version of course).
• Open a new CMD
• Enter something along the line of: set PATH=C:\Dev\MinGW32-PosixDwarf491r1\bin;%PATH%
• Enter cmake-gui to open CMake with the right PATH variable set.
• Set all the variables etc and so forth.
• cd to the build directory
• Enter mingw32-make install -j8

The curcial part is here, that PATH isn't "contaminated" by some odd MinGW install, that I specify which compiler I want to use by manually adding it to PATH and by launching CMake through the CMD, which will automatically serve the right PATH variables. If you start CMake via Explorer it will still use the system wide set PATH variables.

I can't recommend cygwin.

Running "cmake-gui" in a cmd terminal doesn't work even when I reinstall CMake with the install setting to add itself to PATH.  It just says it's not a recognized command. For the record, it does seem to recognize "mingw32-make" as a command.

Running it from the Start Menu, it gives the same errors as before even after following the PATH-related steps. you specified.

Though the .dll error seems to have stopped, so I'm guessing those PATH changes fixed that at least.

[Ixrec]

After manually adding the other version of CMake to my system path, cmd recognizes cmake-gui as a command.

Still no change to the CMake errors after following your steps.  Could you clarify exactly what I do between these two steps?

Enter cmake-gui to open CMake with the right PATH variable set.
Set all the variables etc and so forth.

Because the Configure step always fails, I never get to the part where I can set any variables.  The only thing I have control over in CMake is the generator and possibly specifying the native compilers.  Is there any point fiddling with those or is "Unix Makefiles" and "default" correct?

[Ixrec]

I stumbled across someone claiming they worked around CMake problems by manually defining CMAKE_MAKE_PROGRAM, so I tried that.

Interestingly, that did get it farther along, though now it fails with:

The C compiler identification is GNU 4.9.1
The CXX compiler identification is GNU 4.9.1
Check for working C compiler: C:/Program Files (x86)/mingw32/bin/gcc.exe
Check for working C compiler: C:/Program Files (x86)/mingw32/bin/gcc.exe -- broken
CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/CMakeTestCCompiler.cmake:61 (message):
  The C compiler "C:/Program Files (x86)/mingw32/bin/gcc.exe" is not able to
  compile a simple test program.

  It fails with the following output:

   Change Dir: C:/Users/Ixrec/My Code/SFML build (git master)/CMakeFiles/CMakeTmp

 

  Run Build Command:"C:/PROGRA~2/mingw32/bin/g++.exe"
  "cmTryCompileExec235575778/fast"

  g++.exe: error: cmTryCompileExec235575778/fast: No such file or directory


  g++.exe: fatal error: no input files


  compilation terminated.


 

 

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


Configuring incomplete, errors occurred!
See also "C:/Users/Ixrec/My Code/SFML build (git master)/CMakeFiles/CMakeOutput.log".
See also "C:/Users/Ixrec/My Code/SFML build (git master)/CMakeFiles/CMakeError.log".

Edit: After moving all these MinGWs and Clang to my Desktop to rule out permission errors, I have finally gotten one of them to compile a Hello World program (and print the size of a void pointer, which is apparently 4 even though I'm on a 64-bit machine).  Clang still can't find the iostream header, and all the CMake errors remain identical even after redoing all the PATH change and cmd commands.


Edit: I'm even trying the CMake command line now. Was able to reproduce exactly the same error:

C:\Users\Ixrec\Desktop\mingw32>cmake -D"CMAKE_MAKE_PROGRAM:PATH=C:\Users\Ixrec\D
esktop\mingw32\bin\make.exe" -D"CMAKE_CXX_COMPILER:PATH=C:\Users\Ixrec\Desktop\m
ingw32\bin\g++.exe" -D"CMAKE_C_COMPILER:PATH=C:\Users\Ixrec\Desktop\mingw32\bin\
gcc.exe" -G"Unix Makefiles" "C:\Users\Ixrec\My Code\SFML source (git master)\"
-- The C compiler identification is GNU 4.9.1
-- The CXX compiler identification is GNU 4.9.1
-- Check for working C compiler: C:/Users/Ixrec/Desktop/mingw32/bin/gcc.exe
CMake Error: Generator: execution of make failed. Make command was: "C:/Users/Ix
rec/Desktop/mingw32/bin/make.exe" "cmTryCompileExec1233230271/fast"
-- Check for working C compiler: C:/Users/Ixrec/Desktop/mingw32/bin/gcc.exe -- b
roken
CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.0/Modules/CMakeTestCCo
mpiler.cmake:61 (message):
  The C compiler "C:/Users/Ixrec/Desktop/mingw32/bin/gcc.exe" is not able to
  compile a simple test program.

  It fails with the following output:

   Change Dir: C:/Users/Ixrec/Desktop/mingw32/CMakeFiles/CMakeTmp



  Run Build Command:"C:/Users/Ixrec/Desktop/mingw32/bin/make.exe"
  "cmTryCompileExec1233230271/fast"

  The system cannot find the file specified

  Generator: execution of make failed.  Make command was:
  "C:/Users/Ixrec/Desktop/mingw32/bin/make.exe"
  "cmTryCompileExec1233230271/fast"





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


-- Configuring incomplete, errors occurred!
See also "C:/Users/Ixrec/Desktop/mingw32/CMakeFiles/CMakeOutput.log".
See also "C:/Users/Ixrec/Desktop/mingw32/CMakeFiles/CMakeError.log".

[eXpl0it3r]

It seems like you don't understand the idea behind PATH and how GCC and CMake work with each other. Sorry if you already know all this, I just don't know where else I could point you to.

PATH is the Windows environment variable which tells the system where it can find "commands". When you open a CMD, you get a number of commands that the terminal understands, but if a directory with for example the executable abc.exe is added to PATH, then you can simply type "abc" and the command line will find the executable via the PATH variable. This however doesn't just apply to executables, if there's a DLL in a directory which is added to PATH, every application can find this DLL.

GCC follows the Unix principle where one application is for one task, thus to compile something you need a whole set of different exe and dlls. To guarantee that everything can be properly found, the bin/ directory of the MinGW version needs to be added to PATH. This can be done globally or like I explained just for one CMD instance.

Setting PATH in a CMD will only set the PATH for that instance and will serve it to all the applications you start from within that instance. If you set PATH in there and then start an application outside it, the outside application won't be able to use the PATH you set inside the command line.

CMake now simply goes and searches for gcc.exe, g++.exe, etc. If the bin/ directory of MinGW has been added to PATH, it will automatically find all the necessary tools. If it's not in PATH, then it will simply fail. One can as you've noticed specify the path to the specific binaries manually, but this can also bring other issues.

I don't know what's advised, but personally I'd say, don't but MinGW into the Program Files directory, because this will only cause permission issues.

"-- Building for: NMake Makefiles" this says you're trying to build NMake Makefiles. NMake is the "makefile" generator for Visual Studios. What you need is MinGW Makefiles (or similar).

[Ixrec]

Pretty much all of that stuff about PATH I've always known.  The fact that I understand it conceptually does not mean I have any way of knowing when a random error message is due to a program being completely broken or a configuration step no one told me about or who knows what.  I generally assume that rudimentary system settings like this get automatically configured by installers because, after all, that's exactly what installers are supposed to do, and pretty much every Windows program I've ever encountered that isn't a GNU/Linux/etc thing seems to do this properly.  And none of the tutorials/instructions I saw ever mentioned a need to set these things manually; only troubleshooting threads mention these PATH changes as "last resorts".


I'm not sure how many of my edits you noticed, but from the last set of errors it's fairly clear that even specifying every path that could conceivably matter still does not get CMake past the test program phase.  It looks like g++ just isn't able to process the relative filepath CMake is giving it.  Surely we aren't supposed to add CMake temporary directories to the PATH variable, right?  I actually tried adding . to PATH already and that didn't affect it.

[eXpl0it3r]

I've sent you a PM (in case you miss it while refreshing this page).