There appear to be conflicting definitions in the ~clusapi.h~ header.
$ cat junk.cc #define _WIN32_WINNT 0x0601 #include <windows.h> #include <resapi.h> int WinMain( int argc, char **argv ) { return 0; } $ x86_64-w64-mingw32-g++ -c junk.cc 2>&1 | head -30 In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/resapi.h:11:0, from junk.cc:5: /usr/x86_64-w64-mingw32/sys-root/mingw/include/clusapi.h:1097:14: error: multiple definition of 'enum CLUSTER_RESOURCE_STATE' typedef enum CLUSTER_RESOURCE_STATE { ^ In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/resapi.h:11:0, from junk.cc:5: /usr/x86_64-w64-mingw32/sys-root/mingw/include/clusapi.h:227:16: error: previous definition here typedef enum CLUSTER_RESOURCE_STATE { ^ In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/resapi.h:11:0, from junk.cc:5: /usr/x86_64-w64-mingw32/sys-root/mingw/include/clusapi.h:1107:25: error: invalid type in declaration before ';' token } CLUSTER_RESOURCE_STATE; ^ /usr/x86_64-w64-mingw32/sys-root/mingw/include/clusapi.h:1107:25: error: conflicting declaration 'typedef int CLUSTER_RESOURCE_STATE' In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/resapi.h:11:0, from junk.cc:5: /usr/x86_64-w64-mingw32/sys-root/mingw/include/clusapi.h:230:5: error: 'CLUSTER_RESOURCE_STATE' has a previous declaration as 'typedef enum CLUSTER_RESOURCE_STATE CLUSTER_RESOURCE_STATE' } CLUSTER_RESOURCE_STATE; ^
It looks like there is a similar problem in resapi.h
There is neither
clusapi.h
norresapi.h
in our W32API; perhaps there should be, but that would require someone to develop them, based entirely on MSDN documentation, and not simply copied from some other project, which may have plagiarised Microsoft copyrighted sources, or have created a bug-ridden implementation from which we have no desire to inherit the bugs.As it stands, I don't see how this can be a MinGW.org bug. There's not much we can do about fixing some other project's bugs, so I'm redesignating this as a feature request; we may consider carefully crafted implementations of the two headers in question, as possible additions to our W32API implementation.