0

I am receiving a perplexing compiler error while trying to use MSYS2's SDL2 / GLEW / OpenGL:

In file included from /m/gstest/inc/graphics/GraphicsSystem.h:36:0,
                 from /m/gstest/src/main.cpp:1:
/c/msys64/mingw64/include/GL/glew.h:233:0: warning: "APIENTRY" redefined
 #define APIENTRY
 ^
In file included from /usr/include/w32api/windef.h:8:0,
                 from /m/gstest/inc/graphics/GraphicsSystem.h:33,
                 from /m/gstest/src/main.cpp:1:
/usr/include/w32api/minwindef.h:103:0: note: this is the location of the previous definition
 #define APIENTRY WINAPI
 ^

GraphicsSystem.h:

// Must come before glew
#include <windef.h>

// Must come before OpenGL (SDL)
#include "glew.h"
//#include "glxew.h"
//#include "wglew.h"

#include "SDL.h"
#include "SDL_opengl.h"
#include "SDL_syswm.h"

I am not sure if this is possibly intended or not. There is a define above the one triggering the warning, wrapped in an #else of an #ifdef APIENTRY. The warning is triggered by:

#define GLEW_APIENTRY_DEFINED
#define APIENTRY // <-- Line 233 glew.h

This seems related to numerous other questions, but most of which discuss the order of includes - this order appears like it should work based on them:

Normally I would not be too bothered by this, but I am also getting errors preventing my build due to issues with what seems to be APIENTRY in SDL's included headers. For example:

In file included from /usr/include/w32api/winbase.h:15:0,
                 from /usr/include/w32api/windows.h:70,
                 from /c/msys64/mingw64/include/SDL2/SDL_opengl.h:40,
                 from /m/gstest/inc/graphics/GraphicsSystem.h:41,
                 from /m/gstest/src/main.cpp:1:
/usr/include/w32api/debugapi.h:27:31: error: expected initializer before 'Contin
ueDebugEvent'
   WINBASEAPI WINBOOL APIENTRY ContinueDebugEvent (DWORD dwProcessId, DWORD dwThreadId, DWORD dwContinueStatus);
                               ^

This seems an unusual coincidence, as I rarely have had issues of this sort, only to have the warning and error together.

Why would glew.h have a second set of #defines which overwrite any previous #defines, when it goes to such ends as to prevent breaking them (for good reason)? That seems destined to cause errors down the road. Is my package of glew simply broken?

Community
  • 1
  • 1
  • It's odd that you are using headers from /usr/include (the msys-2.0.dll-based toolchain) and also using headers from /mingw64/include (the mingw-w64 toolchain). These toolchains are not supposed to be mixed and matched; you should pick one and stick with it. I recommend using mingw-w64 if you can because it compiles native Windows binaries that doesn't need the POSIX emulation provided by msys-2.0.dll. – David Grayson Dec 21 '15 at 05:27

1 Answers1

0

It seems this is due to this version/build of g++ not defining _WIN32, which is causing glew to traverse the Unix-branch of the preprocessor directives, breaking the APIENTRY definition. As such, this is actually not a problem with GLEW at all.

Apparently, this is intended behavior on the part of MSYS2's g++, although I am skeptical as to the wisdom of it. The proper solution is to add -mwin32 to your compiler flags. This will declare _WIN32 as normal and avoid Unix-style libraries getting confused about their platform.