-1

EDIT:

I gave up on making the SDK work properly and instead am using MinGW's provided Windows headers. As for the issue with SDL, I just commented out some lines about Windows RT, which in my case is probably fine as I never plan to compile for mobile devices.

I recently went and grabbed the Windows SDK 8.1 to replace 7.1, which I had to do because I went and grabbed SDL 2.0.3 to replace 2.0.1, and SDL now depends on a file "winapifamily.h" which is only in the 8.x SDK and not 7.x, and it wasn't that big a deal... until I went over to a networking project I've been working on. My code is not the problem, it's my environment. Now that the newer SDK is set up, winnt.h is causing massive problems.

C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|940|error: #error Must define a target architecture.| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|1311|error: 'EXCEPTION_DISPOSITION' does not name a type| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|1320|error: 'EXCEPTION_ROUTINE' does not name a type| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'BYTE ReadUCharAcquire(const volatile BYTE*)':| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8287|error: 'ReadAcquire8' was not declared in this scope| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'BYTE ReadUCharNoFence(const volatile BYTE*)':| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8298|error: 'ReadNoFence8' was not declared in this scope| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'void WriteUCharRelease(volatile BYTE*, BYTE)':| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8321|error: 'WriteRelease8' was not declared in this scope| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'void WriteUCharNoFence(volatile BYTE*, BYTE)':| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8334|error: 'WriteNoFence8' was not declared in this scope| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'WORD ReadUShortAcquire(const volatile WORD*)':| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8359|error: 'ReadAcquire16' was not declared in this scope| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'WORD ReadUShortNoFence(const volatile WORD*)':| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8370|error: 'ReadNoFence16' was not declared in this scope| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h||In function 'void WriteUShortRelease(volatile WORD*, WORD)':| C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h|8393|error: 'WriteRelease16' was not declared in this scope| ||More errors follow but not being shown.| ||Edit the max errors limit in compiler options...| ||=== Build finished: 10 errors, 0 warnings (0 minutes, 39 seconds) ===|

I have been tampering with my environment for about eight hours now and even re-installed MinGW thinking that perhaps it had some outdated headers or libs or something. It is probably something very simple I'm missing, if anyone has any idea what could be causing these issues I would appreciate any help.

Does Microsoft just write unreliable headers? Is the SDK only for Visual Studio compilers, and if so why are there many instances of the letters 'GNU' and 'GCC' in many Windows headers, even winnt.h?

Sam
  • 7,252
  • 16
  • 46
  • 65
rsethc
  • 2,485
  • 2
  • 17
  • 27
  • Is this a duplicate of http://stackoverflow.com/questions/2022112/can-g-mingw-play-nice-with-the-windows-sdk-is-visual-studio-the-only-option? – rfernandes Mar 27 '14 at 03:35
  • I wish. I tried adding -mwindows and it helped none. I didn't need it before, though... only the new SDK has this issue. – rsethc Mar 27 '14 at 20:18
  • I would suggest then peeking into winnt.h and winapifamily.h to see what #defines they are expecting - it may end up being something simple that will only require you to add a "-D" to your CFLAGS variable in your makefile... – rfernandes Mar 27 '14 at 22:24
  • I am worried that if I tamper with the file I will break something, or if I define something that will silence the error then it will produce an inconsistency, because I never had to do any defines with the 7.x SDK. So perhaps yes it is some flag I need to add, but I don't use a makefile. What is this -D you are talking about though? – rsethc Mar 27 '14 at 23:56
  • You don't need to change anything in those files, but just check what sort of #ifdef's are in them - for example, if you look around line 940 in winnt.h, you'll see that it is inside a `#if...#else...#endif` block. You will then be able to see the flags that it is expecting to see. When you know what they are, you can call gcc like `gcc -D myprog myprog.c` – rfernandes Mar 28 '14 at 00:07
  • But the problem is I can't tell if they're internal flags. The ones I see are like "_IA64_" for that block, but for example if that one was defined somewhere in another Windows header based on another one, then although I could trace it I'd rather just find out why it's not doing that on its own. – rsethc Mar 28 '14 at 01:56
  • Another thing to try is simply to get Visual C++ Express, create a project including those libraries and see which flags the compiler is using in the project settings. – rfernandes Mar 28 '14 at 02:33
  • I'd prefer to not use VS ever. – rsethc Mar 29 '14 at 15:54
  • Should I delete this question since I've given up on it? – rsethc Mar 30 '14 at 15:11

1 Answers1

1

I know this is a bit too late, but for those with still the same problem.
The problem indeed stems from the environment. Particularly, from the include directories pointing to 2 different versions of winnt.h and in your case, probably also winsock2.h given that you say it is a network app you're dealing with.
Background: there are 2 lists of include files in your proyect. One comes from your proyect settings, the second one comes from the global includes defined in the compiler settings, in that order.
Perhaps, in your previous configuration, winnt.h, winsock2.h etc. were taken from the global settings, which pointed to the Mingw provided files, but now, for sure, they are in the include paths of the SDK (that happend to me as well).
Your problem is one of precedence. The "windows" files from the SDK don't work with Mingw, so much that Mingw includes those files, but modified.
What you have to do is, put on top of the list, in your proyect settings' include directories, the same directory that you find in the global settings that point to the Mingw provided files, in such a way that these windows files are taken from the ones included in Mingw and not the SDK.
Hope this helps.

Alfredo Meraz
  • 139
  • 1
  • 7