Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Compiling SFML2 with mingw64-w64 #132

Closed
BMBurstein opened this Issue · 13 comments

6 participants

Baruch Fanael Linithien Patrick Dinklage Ruben Van Boxem Laurent Gomila Peter Atashian
Baruch

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

Fanael Linithien

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

Baruch

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

Patrick Dinklage

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.

Baruch

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.

Ruben Van Boxem

Hi,
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"
mingw32-make

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

Baruch

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.

Ruben Van Boxem

I would suggest not doing any black magic like mentioned in http://en.sfml-dev.org/forums/index.php?topic=7604.msg51664#msg51664 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.

Laurent Gomila

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).

Ruben Van Boxem

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?

Laurent Gomila

Nop.

Peter Atashian

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.

Laurent Gomila

However, trying to link in glew causes issues.

Only under specific conditions... right?

Laurent Gomila

Fixed by #218

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.