Compiling SFML2 with mingw64-w64 #132

BMBurstein opened this Issue Dec 13, 2011 · 13 comments

6 participants


I am trying to compile the latest version of SFML2. I am on windows 7 (64 bit), using the mingw-64-w64 compiler. The CMake ran fine (eventually), but when I run mingw32-make (that is what comes with the compiler. I don't think there is a mingw64-make), it stops at 32% with the error:

C:\Users\Baruch\progs\mingw64\bin\ar.exe: C:/Users/Baruch/progs/mingw64/lib/libopengl32.a: No such file or directory

I eventually found the file, but it is not under lib, it is under x86_64-w64-mingw32/lib. I updated this in the cmake, but it got stuck on other files, that are also in x86_64-w64-mingw32/lib or x86_64-w64-mingw32/lib32

This only applies to the mingw64-w64 (produces native 64-bit code) build, not the mingw64-w32


Looks like a toolchain bug to me, unrelated to SFML at all.


I think it should (maybe) be updated in the CMake files to find these files.


I can't even link SFML for 64-bit in this kind of environment, because the library files provided in "extlib/libs-mingw" are only 32-bit libraries. SFML should probably provide both the 32 and 64 bit libraries for MinGW like it does for MSVC.


I just tried again on a 32-bit windows XP, using the 32-bit build, and I got stuck there again. Upon very clode inspection, I found the problem command to be:

cd /d D:\Programming\SFML2\CMake\src\SFML\Window && D:\Programming\ruben_4.7.0-3\mingw32\bin\ar.exe x D:/Programming/ruben_4.7.0-3/mingw32/lib/libopengl32.a

which is nested deep in the CMake generated files.


I am the guy who built the MinGW-w64 toolchain in question, and I can vouch for its correctness/usability for OpenGL.
I believe this may be a CMake booboo. When I used CMake 2.8.7, I got a makefile dependency error, upgrading to CMake 2.8.8 solved this issue, and allowed me to build a 32-bit SFML with my GCC 4.7.0 build mentioned above.
The exact commands used to build are:

cmake ../../Source/SFML -G"MinGW Makefiles"

A 64-bit build results in undefined reference errors to FT_* symbols, which I believe is Freetype and thus logical because the deps aren't included. I took the liberty of opening an issue report: #217


I found the problem, and it only applies to building SFML as static libraries, which is not the default. It has the <mingw>/lib directory hard-coded in.


I would suggest not doing any black magic like mentioned in and instead just link with "-lopengl32". There is no static version [necessary|available|useful] for the Windows system DLL "opengl32.dll". There's no harm in linking it in a normal way. "libopengl32.a" is an import library for Windows' DLL file, always has been.

Simple and Fast Multimedia Library member

I'm doing black magic so that when you link your application to static SFML libraries, you don't have to link to all its dependencies too, it's automatically done. It's not the regular way of handling static libraries, but it's definitely very convenient for the end user.

However, this might become optional in the future (it's currently being tested by our friends of SFGUI).


Won't this "black magic" cause multiple definition errors when the user links to SFML and opengl32, because all symbols in opengl32 are also in SFML?

Simple and Fast Multimedia Library member



I've used statically built SFML libraries for a long time. I've been able to link in opengl without any issues.
However, trying to link in glew causes issues. So if I want to use a newer version of glew, I'm forced to either use the shared libraries or modify SFML to use a newer glew.

Simple and Fast Multimedia Library member

However, trying to link in glew causes issues.

Only under specific conditions... right?

Simple and Fast Multimedia Library member

Fixed by #218

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment