Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows build fails due to conflicting types for 'XINPUT_GAMEPAD_EX' #2417

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Closed

Comments

@SDLBugzilla
Copy link
Collaborator

SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 2.0.5
Reported for operating system, platform: Windows 7, x86_64

Comments on the original bug report:

On 2017-03-17 09:44:40 +0000, Mario Emmenlauer wrote:

When building on MSYS2 for Windows x86_64 target, the build fails with
latest MinGW64 due to a conflicting type 'XINPUT_GAMEPAD_EX'. The upstream
update of MinGW headers that brought the conflict was
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/c628bd49a2c8cdee2250430c8d7b7cd95f1fe90a

However the headers seem correct(?). See the MSYS2 bug tracker here:
https://github.com/Alexpux/MINGW-packages/issues/2300

Error message:

  CC     build/SDL_windowsevents.lo
In file included from ../SDL2-2.0.5/src/core/windows/SDL_xinput.c:24:0:
../SDL2-2.0.5/src/core/windows/SDL_xinput.h:113:3: error: conflicting types for 'XINPUT_GAMEPAD_EX'
 } XINPUT_GAMEPAD_EX;
   ^~~~~~~~~~~~~~~~~
In file included from ../SDL2-2.0.5/src/core/windows/SDL_xinput.h:29:0,
                 from ../SDL2-2.0.5/src/core/windows/SDL_xinput.c:24:
D:/bda-ci/msys2/testing/mingw64/x86_64-w64-mingw32/include/xinput.h:182:3: note: previous declaration of 'XINPUT_GAMEPAD_EX' was here
 } XINPUT_GAMEPAD_EX, *PXINPUT_GAMEPAD_EX;
   ^~~~~~~~~~~~~~~~~
In file included from ../SDL2-2.0.5/src/core/windows/SDL_xinput.c:24:0:
../SDL2-2.0.5/src/core/windows/SDL_xinput.h:119:3: error: conflicting types for 'XINPUT_STATE_EX'
 } XINPUT_STATE_EX;
   ^~~~~~~~~~~~~~~
In file included from ../SDL2-2.0.5/src/core/windows/SDL_xinput.h:29:0,
                 from ../SDL2-2.0.5/src/core/windows/SDL_xinput.c:24:
D:/bda-ci/msys2/testing/mingw64/x86_64-w64-mingw32/include/xinput.h:192:3: note: previous declaration of 'XINPUT_STATE_EX' was here
 } XINPUT_STATE_EX, *PXINPUT_STATE_EX;
   ^~~~~~~~~~~~~~~
make: *** [Makefile:547: build/SDL_xinput.lo] Error 1
make: *** Waiting for unfinished jobs....
==> ERROR: A failure occurred in build().
    Aborting...

On 2017-04-27 05:34:00 +0000, Mario Emmenlauer wrote:

This seems to affect more MSYS2 users now.

On 2017-05-21 16:10:18 +0000, wrote:

I've managed to fix this on MinGW-w64(gcc version 6.3.0) and MinGW 32-bit(gcc version 5.3.0) by modifiying the SDL_XInput.h, by wrapping the two type definitions within a #ifndef to make it not define those structures on version 6.3.0+(Don't know the exact version when these defines are added, since I don't know the version of the commit adding it to the SDL):

------------------------------------------
/* typedef's for XInput structs we use */
#ifdef __MINGW32__
#if ((__GNUC__ << 16) + __GNUC_MINOR__ >= ((6) << 16) + (3))
//We're defined on gcc 6.3+(MinGW)
#define HAS_XINPUT_GAMEPAD_EX
#define HAS_XINPUT_STATE_EX
#endif
#endif

#ifndef HAS_XINPUT_GAMEPAD_EX
typedef struct
{
    WORD wButtons;
    BYTE bLeftTrigger;
    BYTE bRightTrigger;
    SHORT sThumbLX;
    SHORT sThumbLY;
    SHORT sThumbRX;
    SHORT sThumbRY;
    DWORD dwPaddingReserved;
} XINPUT_GAMEPAD_EX;
#endif

#ifndef HAS_XINPUT_STATE_EX
typedef struct
{
    DWORD dwPacketNumber;
    XINPUT_GAMEPAD_EX Gamepad;
} XINPUT_STATE_EX;
#endif

------------------------------------------

Although, it's just a little wrapper for version 6.3.0+ MinGW to not use those type definitions(as it should be in the headers already). The 32-bit version (according to the MinGW installation manager) is 5.0.3-3(which is the repository version according to the MinGW installation manager).

On 2017-05-21 16:16:57 +0000, wrote:

Btw, I've applied this to the current SDL2 mecurial code. The update adding this to the MinGW headers seems to be https://sourceforge.net/p/mingw-w64/mingw-w64/ci/c628bd49a2c8cdee2250430c8d7b7cd95f1fe90a .

The current SDL2 mecurial commit seems to be https://hg.libsdl.org/SDL/rev/7860594a8ad7 .

On 2017-05-21 20:10:51 +0000, Mario Emmenlauer wrote:

Thanks a lot! I'll test when I find a bit of time.

On 2017-05-24 20:33:42 +0000, Ryan C. Gordon wrote:

So do we need to do something now, or is this taken care of for MingW64 users on their end of things?

--ryan.

On 2017-05-25 12:09:52 +0000, wrote:

(In reply to Ryan C. Gordon from comment # 5)

So do we need to do something now, or is this taken care of for MingW64
users on their end of things?

--ryan.

I think it would either need to be added to MinGW32(to increase compatibility, with a newer gcc compiler version, upgrading the toolchain), or added to SDL2 for compatibility with the older gcc version(MinGW32). Adding the fix to SDL2 would fix both older and newer compiler versions, both on x86 and x64 versions. Although I don't know at what version the https://sourceforge.net/p/mingw-w64/mingw-w64/ci/c628bd49a2c8cdee2250430c8d7b7cd95f1fe90a commit was implemented in, nor for a proper way to detect it(other than the 6.3.* compiler version detection).

On 2017-05-25 13:02:06 +0000, wrote:

(In reply to superfury from comment # 6)

(In reply to Ryan C. Gordon from comment # 5)

So do we need to do something now, or is this taken care of for MingW64
users on their end of things?

--ryan.

I think it would either need to be added to MinGW32(to increase
compatibility, with a newer gcc compiler version, upgrading the toolchain),
or added to SDL2 for compatibility with the older gcc version(MinGW32).
Adding the fix to SDL2 would fix both older and newer compiler versions,
both on x86 and x64 versions. Although I don't know at what version the
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/
c628bd49a2c8cdee2250430c8d7b7cd95f1fe90a commit was implemented in, nor for
a proper way to detect it(other than the 6.3.* compiler version detection).

Looking the fault itself up, it seems to have been around since about version 5.0.2, but not all of those compilers based on that version seem have it. So maybe on all versions higher than 5.0.2, apply this update(define those two defines)?

On 2017-06-06 12:44:07 +0000, Mario Emmenlauer wrote:

Sorry that I lost track: is the fix already in trunk? Or should I make a small patch for MSYS2 for the time being? Thanks a lot for your help!

On 2017-06-06 16:43:05 +0000, Ryan C. Gordon wrote:

I've put this patch in as https://hg.libsdl.org/SDL/rev/117d4ce1390e ...can you verify this works on the latest MinGW?

Thanks,
--ryan.

On 2017-06-06 20:23:33 +0000, Ozkan Sezer wrote:

(In reply to Ryan C. Gordon from comment # 9)

I've put this patch in as https://hg.libsdl.org/SDL/rev/117d4ce1390e ...can
you verify this works on the latest MinGW?

Thanks,
--ryan.

This patch is wrong: the structure in question has nothing to do with any
gcc version in use. I suggest reverting this adding a conigury check for
it, instead. Something like the following should do it: (configure needs
regenerating.)

diff -r 8a29b371e2db CMakeLists.txt
--- a/CMakeLists.txt	Tue Jun 06 14:06:40 2017 -0400
+++ b/CMakeLists.txt	Tue Jun 06 23:21:42 2017 +0300
@@ -1092,6 +1092,16 @@
         #include <windows.h>
         #include <xinput.h>
         int main(int argc, char **argv) { }" HAVE_XINPUT_H)
+      check_c_source_compiles("
+        #include <windows.h>
+        #include <xinput.h>
+        XINPUT_GAMEPAD_EX x1;
+        int main(int argc, char **argv) { }" HAVE_XINPUT_GAMEPAD_EX)
+      check_c_source_compiles("
+        #include <windows.h>
+        #include <xinput.h>
+        XINPUT_STATE_EX s1;
+        int main(int argc, char **argv) { }" HAVE_XINPUT_STATE_EX)
     else()
       check_include_file(xinput.h HAVE_XINPUT_H)
     endif()
diff -r 8a29b371e2db configure.in
--- a/configure.in	Tue Jun 06 14:06:40 2017 -0400
+++ b/configure.in	Tue Jun 06 23:21:42 2017 +0300
@@ -2716,6 +2716,16 @@
         AC_CHECK_HEADER(dxgi.h, have_dxgi=yes)
         AC_CHECK_HEADER(xaudio2.h, have_xaudio2=yes)
         AC_CHECK_HEADER(xinput.h, have_xinput=yes)
+        AC_TRY_COMPILE([
+#include <windows.h>
+#include <xinput.h>
+XINPUT_GAMEPAD_EX x1;
+        ],[],[have_xinput_gamepadex=yes])
+        AC_TRY_COMPILE([
+#include <windows.h>
+#include <xinput.h>
+XINPUT_STATE_EX s1;
+        ],[],[have_xinput_stateex=yes])
 
         if test x$have_ddraw = xyes; then
             AC_DEFINE(HAVE_DDRAW_H, 1, [ ])
@@ -2732,6 +2742,12 @@
         if test x$have_xinput = xyes; then
             AC_DEFINE(HAVE_XINPUT_H, 1, [ ])
         fi
+        if test x$have_xinput_gamepadex = xyes; then
+            AC_DEFINE(HAVE_XINPUT_GAMEPAD_EX, 1, [ ])
+        fi
+        if test x$have_xinput_stateex = xyes; then
+            AC_DEFINE(HAVE_XINPUT_STATE_EX, 1, [ ])
+        fi
 
         SUMMARY_video="${SUMMARY_video} directx"
         SUMMARY_audio="${SUMMARY_audio} directx"
diff -r 8a29b371e2db include/SDL_config.h.cmake
--- a/include/SDL_config.h.cmake	Tue Jun 06 14:06:40 2017 -0400
+++ b/include/SDL_config.h.cmake	Tue Jun 06 23:21:42 2017 +0300
@@ -55,6 +55,8 @@
 #cmakedefine HAVE_XAUDIO2_H @HAVE_XAUDIO2_H@
 #cmakedefine HAVE_XINPUT_H @HAVE_XINPUT_H@
 #cmakedefine HAVE_DXGI_H @HAVE_DXGI_H@
+#cmakedefine HAVE_XINPUT_GAMEPAD_EX @HAVE_XINPUT_GAMEPAD_EX@
+#cmakedefine HAVE_XINPUT_STATE_EX @HAVE_XINPUT_STATE_EX@
 
 /* Comment this if you want to build without any C library requirements */
 #cmakedefine HAVE_LIBC 1
diff -r 8a29b371e2db include/SDL_config.h.in
--- a/include/SDL_config.h.in	Tue Jun 06 14:06:40 2017 -0400
+++ b/include/SDL_config.h.in	Tue Jun 06 23:21:42 2017 +0300
@@ -55,6 +55,8 @@
 #undef HAVE_DSOUND_H
 #undef HAVE_DXGI_H
 #undef HAVE_XINPUT_H
+#undef HAVE_XINPUT_GAMEPAD_EX
+#undef HAVE_XINPUT_STATE_EX
 
 /* Comment this if you want to build without any C library requirements */
 #undef HAVE_LIBC
diff -r 8a29b371e2db include/SDL_config_windows.h
--- a/include/SDL_config_windows.h	Tue Jun 06 14:06:40 2017 -0400
+++ b/include/SDL_config_windows.h	Tue Jun 06 23:21:42 2017 +0300
@@ -82,6 +82,8 @@
 #define HAVE_DSOUND_H 1
 #define HAVE_DXGI_H 1
 #define HAVE_XINPUT_H 1
+#define HAVE_XINPUT_GAMEPAD_EX 1
+#define HAVE_XINPUT_STATE_EX 1
 
 /* This is disabled by default to avoid C runtime dependencies and manifest requirements */
 #ifdef HAVE_LIBC
diff -r 8a29b371e2db src/core/windows/SDL_xinput.h
--- a/src/core/windows/SDL_xinput.h	Tue Jun 06 14:06:40 2017 -0400
+++ b/src/core/windows/SDL_xinput.h	Tue Jun 06 23:21:42 2017 +0300
@@ -101,13 +101,7 @@
 
 /* typedef's for XInput structs we use */
 
-/* Don't redeclare these on MinGW with gcc >= 5.0.2 */
-#if defined(__MINGW32__) && (((__GNUC__ * 10000) + (__GNUC_MINOR__ * 100) + __GNUC_PATCHLEVEL__) >= 50002)
-#define HAS_XINPUT_GAMEPAD_EX
-#define HAS_XINPUT_STATE_EX
-#endif
-
-#ifndef HAS_XINPUT_GAMEPAD_EX
+#ifndef HAVE_XINPUT_GAMEPAD_EX
 typedef struct
 {
     WORD wButtons;
@@ -121,7 +115,7 @@
 } XINPUT_GAMEPAD_EX;
 #endif
 
-#ifndef HAS_XINPUT_STATE_EX
+#ifndef HAVE_XINPUT_STATE_EX
 typedef struct
 {
     DWORD dwPacketNumber;

On 2017-06-08 06:00:31 +0000, Ozkan Sezer wrote:

Created attachment 2754
mingw xinput configury patch

Here is a proper patch (attached) with configure regenerated too.

On 2017-06-10 18:06:03 +0000, wrote:

(In reply to Ozkan Sezer from comment # 11)

Created attachment 2754 [details]
mingw xinput configury patch

Here is a proper patch (attached) with configure regenerated too.

Confirmed working on MinGW64(gcc 6.3.0). MinGW32 compiles with errors straight after configuring:

*** START DUMP ***

$ make
/bin/sh ../build-scripts/mkinstalldirs build
mkdir -p -- build
/bin/sh ../build-scripts/updaterev.sh
  CC     build/SDL.lo
In file included from ../src/SDL.c:24:0:
../src/core/windows/SDL_windows.h:67:28: error: unknown type name 'REFIID'
 extern BOOL WIN_IsEqualIID(REFIID a, REFIID b);
                            ^
../src/core/windows/SDL_windows.h:67:38: error: unknown type name 'REFIID'
 extern BOOL WIN_IsEqualIID(REFIID a, REFIID b);
                                      ^
make: *** [build/SDL.lo] Error 1

*** END DUMP ***

I compile it as given below to try to make it not depend on any special dll files in Windows(Windows 95-compatible).

Building on MinGW 32-bit(fails with the above error):

./configure --prefix=/mingw CFLAGS="-g -O3 -DUSING_GENERATED_CONFIG_H -static-libgcc -static-libstdc++"

Building on MinGW 64-bit(succeeds without errors):

./configure --prefix=/mingw CFLAGS="-g -O3 -DUSING_GENERATED_CONFIG_H -static-libgcc -static-libstdc++" --host=x86_64-w64-mingw32

On 2017-06-20 05:58:06 +0000, Ozkan Sezer wrote:

(In reply to superfury from comment # 12)

(In reply to Ozkan Sezer from comment # 11)

Created attachment 2754 [details]
mingw xinput configury patch

Here is a proper patch (attached) with configure regenerated too.

Confirmed working on MinGW64(gcc 6.3.0).

Thanks for confirming. I suggest that this patch be applied to hg.

MinGW32 compiles with errors straight after configuring:

*** START DUMP ***

$ make
/bin/sh ../build-scripts/mkinstalldirs build
mkdir -p -- build
/bin/sh ../build-scripts/updaterev.sh
  CC     build/SDL.lo
In file included from ../src/SDL.c:24:0:
../src/core/windows/SDL_windows.h:67:28: error: unknown type name 'REFIID'
 extern BOOL WIN_IsEqualIID(REFIID a, REFIID b);

Several headers from mingw.org are very broken. The specific error you
report can be fixed by including basetyps.h. Like so:

diff -r 5f33dc4d399e src/core/windows/SDL_windows.h
--- a/src/core/windows/SDL_windows.h	Sun Jun 18 23:00:42 2017 +0200
+++ b/src/core/windows/SDL_windows.h	Tue Jun 20 08:55:02 2017 +0300
@@ -35,6 +35,7 @@
 #endif
 
 #include <windows.h>
+#include <basetyps.h> /* for REFIID with broken mingw.org headers */
 
 /* Routines to convert from UTF8 to native Windows text */
 #if UNICODE

On 2017-07-06 08:25:47 +0000, Ozkan Sezer wrote:

PING ?

On 2017-07-11 01:31:56 +0000, Sam Lantinga wrote:

Fixed, thanks!
https://hg.libsdl.org/SDL/rev/c936a84f05ba

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant