How to build SFML2.1 for TDM-GCC 4.8.1 in cmake?

[magneonx]

Hello, I need to compile SFGUI on my pc but since the instruction on their site requires that SFGUI isn't compatible with MinGW GCC 4.7.1, I need to somehow upgrade my compiler to 4.8.1. And so I did. I have downloaded TDM-GCC 4.8.1 and integrated that to my computer and it seems to work well now and that I have made it to work for C::B version 12.

So I have decided somehow to replace SFML 2.0 with 2.1. So I am on Cmake thingy and I know how to use cmake it just that everytime I hit configure and specify my compilers for TDM gcc and g++ it produces this error for the downloaded 'source' of SFML 2.1:

CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different 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: Could not find cmake module file:C:/libraries/SFML/SFML2.1-build/CMakeFiles/2.8.10.2/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: Could not find cmake module file:C:/libraries/SFML/SFML2.1-build/CMakeFiles/2.8.10.2/CMakeCXXCompiler.cmake
 

I am stuck and I lost. I am able to build SFML 2.0 src with no problem when I build it for 4.7.1 now I can't seem to manage this error.

I am using TDM MinGW 4.8.1 on 64bit Windows 7.

[eXpl0it3r]

Even though I don't recommend the use of TDM due to ugly tweaks (I use MinGW Builds), it's the same for this as for all the other versions of "MinGW".
To be able to compile anything via CMake, you need to make sure that the compiler can be found, thus it has to be in the environment variable PATH. If this is your only MinGW compiler on the system, I suggest you add the compiler permanently to PATH, if it's not, then you can open a command prompt and add the compiler temporarily to PATH, by typing:

set PATH=C:\<path-to-compiler>\bin;%PATH%

After that start CMake with the same command prompt, otherwise the temporarily set PATH, won't apply.

Some times the make program can't be found even though the path to the compiler's bin directory is in PATH. Then you can simply set the CMake variable CMAKE_MAKE_PROGRAM to the make executable (often called mingw32-make.exe).

Edit: Then again... you already knew that?!

[magneonx]

Wow, having said that, I just restarted my computer and it works. Thank you very much. And for the link thank you!!! I have been searching for that in ages! Unbelievable. I have bookmarked it now. Everytime I google it and search for it and even went into StackOveflow and other sites, they always suggest that I can always grab a copy from somewhere in gnu.org/. But when you click that link all it shows is just change note and release date but no download button or any links on that site.

Thank you for giving me that link, I am going to replace my current compiler with the one you suggested.

[eXpl0it3r]

Ah yeah, when you make "global" changes to PATH, you'll often have to logout and log back in, to get it setup up system wide.

No problem, took me a while to find those builds as well.

[magneonx]

Somehow I think I downloaded the wrong build. I have downloaded the sjlj I think I should have downloaded dwarf? My computer complains about the libgcc_s_dw2-1.dll is missing from my computer. I have searched my computer and I cannot find it some I find similar dill named libgcc_s_sjlj-1.dll I think I should just downloaded the other.

What do you think? How can I solve my problem? libgcc_s_dw2-1.dll is not on my computer. I've searched every drives and the mingw folder but there isn't one there.

I am using codeblocks version 12 anyway.

[eXpl0it3r]

Keep in mind, that if you use the MinGW Builds, you really have to build SFML yourself! And if you build SFML yourself, there should be no problem with incompatibility.

[magneonx]

but it keeps on looking for that .dll is not really even on my computer, anyway I got it to work now, almost. I downloaded the dwarf, then build sfml. Now it looks for SFML .dlls. I have to restart my computer and see what happens next boot.

[Daddi]

@eXpl0it3r
Would you elaborate on why you don't like TDM? What tweaks do you mean?

[eXpl0it3r]

Would you elaborate on why you don't like TDM? What tweaks do you mean?

I can, although you can find a few posts about it already on the forum if you search for them.

You want to know the tweaks or quirks? Well take a look at this long list...
The most annoying thing, is the first part: "TDM-GCC doesn't link your programs with the libgcc or libstdc++ runtime DLLs by default."

This breaks about every interface for GCC-based compilers. What it means is, that the runtime lib will now get linked statically by default and if you want them linked as shared libraries you'll have to specify -shared-libstdc++ and -shared-libgcc.
So do you want to know what the sideeffect of this "little" quirks is? About all build systems/makefiles/etc are broken for all TDM compilers and to get them working, need a special exception for them.

But hey the guys at Code::Blocks "like the TDM builds" and thus don't care at all, that they are essentially setting up a imho broken compiler as default compiler, for many programmers and especially beginners.
I understand the argument by TDragon (creator of the TDM builds), but I don't think it justifies the breaking of all build systems.

Plus apparently the x64 compiler has a few bugs, so yeah no thanks.

Besides that, why go with a strangely modified version, when you can get a version that follows the development of the compiler much closer?

[Daddi]

Yeah, I found some of your posts after I asked here
I personally really liked the idea of not having to think about libgcc and libstdc++, but I must say that I didn't think it through. You're absolutely right about the non-standard behaviour.

I saw that you recommended the "MinGW Builds" distributions and have a question about it (as I'm not very deep into different compilers yet ): Whats the difference to the "standard" MinGW suite from mingw.org? Its pretty confusing to read about different gcc Versions (mingw, tdm, mingw builds etc.) and still finding a "mingw" directory in every one of them. 

[eXpl0it3r]

Yeah, I found some of your posts after I asked here
I personally really liked the idea of not having to think about libgcc and libstdc++, but I must say that I didn't think it through. You're absolutely right about the non-standard behaviour.

Sooner or later you'll have to think about it.

I saw that you recommended the "MinGW Builds" distributions and have a question about it (as I'm not very deep into different compilers yet ): Whats the difference to the "standard" MinGW suite from mingw.org? Its pretty confusing to read about different gcc Versions (mingw, tdm, mingw builds etc.) and still finding a "mingw" directory in every one of them.

Yeah it's confusing and it took me a while to get it as well.
MinGW or MinGW32 is where it all started, a way to use GCC on Windows. At some point someone needed a 64bit version for their company and thus that company created their own version and later on made it Open Source. The guy tried to talk with the MinGW32 team to merge the code base, but because of some idiotic and elitist reasons things didn't work out and MinGW-w64 was born.
From what I understand both versions are based off the official GNU tools, but use different building mechanisms and are of course at different states. While MinGW32 only comes with a 32bit compiler for 32bit applications, MinGW-w64 can do both 32bit and 64bit.

But as with SFML, having a code base (MinGW vs MinGW-w64) doesn't say anything about the builds. That's where packages like MinGW Builds, TDM Builds or rubenvb Builds come into play.
MinGW32 has its own release cycle with their fixed settings.
MinGW-w64 has automated builds, but I've never used them. MinGW-w64 also has personal builds. In the past those were done by a few people, most actively by rubenvb and lately MinGW Builds are taking over.
MinGW Builds provides a various range of builds, so you're not tied to SJLJ or DWARF or pthread or win32 thread, but you got the choice.

So to get back to your question.
There's a code base difference between MinGW32 and MinGW-w64. The differences in builds are mostly just the different settings - which make them still incompatible.

[Daddi]

Thank you, thats a nice explanation. I was already preparing a small tutorial on how to use sfml without an IDE and wanted to use TDM, but I think I have to reconsider now (and use mingw builds)

[magneonx]

woah, there is a lot going in there. I have actually done it! I had made SFGUI and SFML 2.1 work with MinGW 4.8.1.

Thanks a lot for all those info and all the help!

[Daddi]

Which Sources of SFML did you use? I currently run into problems when I try to compile the current sfml-master and link SFML statically. Maybe I should open another thread tomorrow