MinGW-w64 can't resolve threadpoolapiset.h declared functions - c++

Question

When I try to build the following code using MinGW-w64 in Eclipse, I get the error "Function 'CreateThreadpool' could not be resolved"
The code:
#define WINVER 0x0603
#define _WIN32_WINNT 0x603
#include <threadpoolapiset.h>
int main(void)
{
CreateThreadpool(nullptr);
return 0;
}
Note: If I remove the defines for windows version, then I get 2 errors:
'CreateThreadpool' was not declared in this scope
Function 'CreateThreadpool' could not be resolved
This means that the defines are making posible for threadpoolapiset.h header to declare the windows API functions.
So back to the initial example, the problem here is that the linker can't find the library where this function is defined.
According to MSDN this function is defined in library kernel32.lib and DLL kernel32.dll.
I found that in MinGW-w64 directories the kernel32 library is found as libkernel32.a, so I tryed including paths and libraries in C/C++ Build > Settings | Tab 'Tool Settings' > GCC C++ Compiler > Includes
I tryed including the directory, the library file and both. Also I did this in MinGW C++ Linker > Libraries
Does any one know how can I make it work?

Answer 1

The threadpool APIs were only added to the linker files in MinGW 4.0. You will need to upgrade.
Windows
If you downloaded MinGW-w64 through MSYS2, then upgrading should be simple; just follow the instructions here.
If you installed the Win-Builds binary package, simply uninstall that, download the new one, and install it.
If you got your MinGW-w64 as part of an IDE, you'll need to consult the IDE vendors to see how to upgrade.
Linux
Unfortunately MinGW-w64 4.0 is newer than most distributions provide. If you use Ubuntu, 15.10 is just around the corner and that should have it. If not, then you will need to build from source. The process for building from source is a little convoluted; go to the MinGW-w64 IRC channel on OFTC and ask there :/ That's what I had to do, anyway. Good luck.
Note to David Hefferman and company
MinGW-w64 doesn't use the same SDK model Microsoft uses. What is available is based on the version of MinGW used, and new things are added frequently and available in subsequent releases. (In fact the reason to use MinGW-w64 over vanilla MinGW is that it has support for most of the APIs that were introduced starting with XP.)