Broken pkg-config Libs.private OpenGL libraries with MinGW cross compilation.

[dkosmari]

Prerequisite Checklist

• I searched for existing issues to prevent duplicates
• I searched for existing discussions on the forum to prevent duplicates
• I am here to report an issue and not to just ask a question or look for help (use the forum or Discord instead)

Describe your issue here

The sfml-window.pc and sfml-graphics.pc scripts have incorrect expansions for the OpenGL libraries in the Libs.private variable.

When invoking pkg-config --libs --static sfml-window on a MinGW cross-compilation, the OpenGL libraries are reported as opengl32 glu32. Same thing happens with sfml-graphics.

These are not valid libraries for linking, it should either be the full path (e.g. /usr/i686-w64-mingw32/sys-root/mingw/lib/libglu32.a /usr/i686-w64-mingw32/sys-root/mingw/lib/libopengl32.a) or specified with the -l option (e.g. -lglu32 -lopengl32).

This problem does not occur with native Linux compilation; the reported libraries are /usr/lib64/libGL.so /usr/lib64/libGLU.so (although the order should be GLU then GL.)

This problem also does not occur in sfml-audio.pc, where OpenAL is used in Libs.private; it correctly expands to the full path (e.g. /usr/i686-w64-mingw32/sys-root/mingw/lib/libOpenAL32.dll.a).

Your Environment

• OS / distro / window manager: Fedora 39, Mageia 9
• SFML version: 2.6.1
• Compiler / toolchain: MinGW gcc 13.2.1
• Special compiler / CMake flags:
• -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw32.cmake
• -DBUILD_SHARED_LIBS=TRUE
• -DSFML_USE_SYSTEM_DEPS=TRUE
• -DSFML_INSTALL_PKGCONFIG_FILES=TRUE

Steps to reproduce

1. cross-compiling SFML with MinGW:

export MINGW_ROOT=/usr/i686-w64-mingw32/sys-root/mingw
cmake \
    -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw32.cmake \
    -DBUILD_SHARED_LIBS=TRUE \
    -DCMAKE_INSTALL_PREFIX=${MINGW_ROOT} \
    -DCMAKE_VERBOSE_MAKEFILE=TRUE \
    -DSFML_USE_SYSTEM_DEPS=TRUE \
    -DSFML_INSTALL_PKGCONFIG_FILES=TRUE \
    ..
make
sudo make install

2. Run i686-w64-mingw32-pkg-config --libs --static sfml-window

Expected behavior

It should print -lsfml-window -lglu32 -lopengl32 -lsfml-system, which is what can be used by the linker.

Actual behavior

It prints -lsfml-window opengl32 glu32 -lsfml-system, and any attempt to use that for linking causes errors:

/usr/lib/gcc/i686-w64-mingw32/12.2.1/../../../../i686-w64-mingw32/bin/ld: cannot find opengl32: No such file or directory
/usr/lib/gcc/i686-w64-mingw32/12.2.1/../../../../i686-w64-mingw32/bin/ld: cannot find glu32: No such file or directory

[ChrisThrasher]

Is it valid to add a -l before @OPENGL_gl_LIBRARY@ and @OPENGL_glu_LIBRARY@? That would seemingly fix the crosscompilation case but I'm not sure what happens when you add -l before an absolute path.

[dkosmari]

No, it would also be wrong to have -l in front of absolute paths.
I just checked the MSYS2 SFML package (https://packages.msys2.org/base/mingw-w64-sfml), it's also broken, for both MinGW and Clang builds. Cross compilation is not a factor.
It seems the combination of Windows host and non-MSVC causes the problem, perhaps something funny inside FindOpenGL.

Perhaps you could check for Windows, then hardcode the OpenGL libs used in the pkg-config scripts to -lglu32 -lopengl32.
Note that pkg-config has a --msvc-syntax, that automatically rewrites GCC-style arguments into MSVC-style arguments. This would come out as glu32.lib opengl32.lib, which is correct for MSVC. Even if SFML is being built with MSVC, you can write the pkg-config variables as if they were for GCC.

[ChrisThrasher]

Looks like we'll need some very specific solution where we check the value of those two cache variables produced by FindOpenGL.cmake and prepend -l if they're not absolute paths. Can you look into whether CMake (as of version 3.7) has a way of detecting whether a given path is absolute or not?

You might have found something worth reporting to Kitware as a CMake bug. You should consider reaching out. https://gitlab.kitware.com/cmake/cmake/-/issues

[dkosmari]

OpenGL detection is already working for building SFML, right? So all you need is a dedicated variable for the pkg-config scripts, where you hardcode the result for Windows builds, instead of using the detected OpenGL.