procedure entry point could not be located

[Argha]

Okay, so the following error is what I get: http://i.gyazo.com/8f28bc05ae7cf64aff99d4b3955bf06e.png

Translated should be:
The procedure entry point XXX could not be located in the dynamic link lXXX.dll

My mingw version is "gcc version 4.8.1 (GCC)", on the SFML website is "GCC 4.9.2 MinGW (DW2)". Is that an issue? I couldnt find a newer version, I used the one linked on the mingw website.


And issues 2: Is there a way to statically link the runtime libs?

set(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++")
set(SFML_USE_STATIC_STD_LIBS TRUE)

Doesn't work (CMakeLists), I need to have them in the folder or path variable atm

[eXpl0it3r]

My mingw version is "gcc version 4.8.1 (GCC)", on the SFML website is "GCC 4.9.2 MinGW (DW2)". Is that an issue? I couldnt find a newer version, I used the one linked on the mingw website.

If it says on the door "use the red key" but you use the blue key and it doesn't work, what do you think it might be the problem?

The GCC 4.9.2 MinGW (DW2) package was built with this compiler.

[Argha]

Damn, I am such a smart guy
Works like a charm. Any idea for my second question if you are already there?

If I do not include the mingw\bin folder in the system path I need to ship tons of DLL's (libwinpthread-1.dll, ...). Any way to link them statically with cmake?

Again, thanks for solving the first and important issue

[Argha]

Hm, I guess I am just going to include the 14 DLL's when distributing it

[eXpl0it3r]

There are enough CMake resources on the web. You can also look at existing CMake files (e.g. from projects of mine on GitHub or so) to see how to work with it. Best you also read the FindSFML.cmake to understand how you link against SFML with CMake.

[Jesper Juhl]

Hm, I guess I am just going to include the 14 DLL's when distributing it

Honest question. What's the problem with that?
However you are going to ship your application; MSI installer, other installer, zip file or whatever, then whether that installer copies one file or 15 into some directory is going to be completely unnoticed by your users. They will just be launching your app via some menu shortcut or whatnot anyway.
Besides, even if you link SFML statically you still have to ship the Visual Studio redistributable runtime DLLs anyway, so what is a few more files in the big picture?

[Rosme]

@Jesper Juhl: He doesn't use Visual Studio. And he could statically link to the CRT also if he wanted, making a single executable for everything. But truthfully, I don't see the issue with the dlls either. Pretty sure he's going to ship assets with it, so what if there's a few dll with it?

[Jesper Juhl]

Whoops. Somehow I missed the compiler in use   Well, GCC also has a runtime lib you need, so.. 
And yeah, there will probably be sound, graphics and more shipped as well, so why worry about a few libraries?
Also, once you've got your build system set up to automatically gather up the dependencies and create the installer/package, it really doesn't matter if there is 1 file or 1000; it just becomes a "make installer" (or similar) command (preferably done automatically by your CI system).
On the other hand; if you are building everything by hand and manually copying files around, then I can see how 14 extra dlls could be annoying. But why would you do that? And in any case, the solution to that is to stop and start using a proper build and CI system and the whole issue just goes away.
It's so nice to have SCons rules to compile and build packages on multiple platforms and then have buildbot do a build, run unit tests and build packages on all supported platforms and then archive the results every time you do a commit. Doesn't take long to set up but really saves time and worry in the long run (I like such a setup at least).

Edit: another argument against statically linking everything is when you have to ship updates. Sure, you can just re-ship the whole thing or use binary diff's. But it's so much easier to just ship a few updated files (out of the many in total) and you can still use bdiffs for those if you like.

[Argha]

Yeah, I realized there isn't a real problem with it and that's why I wrote I gonne ship them now
Anyways, thanks for all the input and arguments for it. Will use it to convince my team member (he wants everythin static )

Thank you all again !

[Argha]

There are enough CMake resources on the web. You can also look at existing CMake files (e.g. from projects of mine on GitHub or so) to see how to work with it. Best you also read the FindSFML.cmake to understand how you link against SFML with CMake.

Out of interest I tried your CMakeLists.txt file and just changed the path to SFML and had to remove the string CACHE STRING so he didn't ignore the if-statements).

Anyways, now it throws tons of these issues:
D:/Libraries/SFML-2.3.1-gcc/lib/libsfml-window-s.a(GlContext.cpp.obj):GlContext.cpp:(.text+0x1d4): undefined reference to `_imp__glGetIntegerv@8'
D:/Libraries/SFML-2.3.1-gcc/lib/libsfml-window-s.a(GlContext.cpp.obj):GlContext.cpp:(.text+0x20b): undefined reference to `_imp__glGetError@0'
D:/Libraries/SFML-2.3.1-gcc/lib/libsfml-window-s.a(GlContext.cpp.obj):GlContext.cpp:(.text+0x242): undefined reference to `_imp__glEnable@4'
D:/Libraries/SFML-2.3.1-gcc/lib/libsfml-window-s.a(GlContext.cpp.obj):GlContext.cpp:(.text+0x2c9): undefined reference to `_imp__glGetString@4'

I'll really stay with just adding them

[eXpl0it3r]

Read the explanation in the FindSFML.cmake. You need to add the CMake variable for SFML's dependencies.