On Monday 01 June 2015 10:07:56 Edward Diener wrote:
On 6/1/2015 4:02 AM, Andrey Semashev wrote:
I'm puzzled how the function can be not dllimport as it is implemented in kernel32.dll. MS Windows SDK defines WINBASEAPI to be __declspec(dllimport) and so is MinGW64 (see winbase.h and winnt.h). Does clang use its own SDK?
gcc and clang on Windows can use the win32 implementation provided by mingw. Evidently the mingw header files translates WINBASEAPI to be empty.
I will try gcc with mingw64 to see if it is different. Unfortunately I have had problems building/using clang with mingw64 and clang even acknowledges that it only supports mingw and not mingw64 on Windows. The suggested a way to get clang working with mingw64 but I have not been able to make that work.
My understanding is that MinGW (http://mingw.org/) was discontinued in favor of MinGW64 (http://mingw-w64.org/). Not sure if we should support it. Anyway, if it turns out that there is no dllimport just in the MinGW SDK then I'm inclined to think it's a bug in the SDK. If we decide so, we could add a workaround if it is possible to detect that particular SDK.
I have been asked by clang to file a bug report regarding this situation, and wil do that.
Thanks. Could you post the link to the bug report?
Also, is it known for sure that the attribute is what's causing the faulre? Because formally, the winapi declaration also involves structures different from those in windows.h and I don't see an easy way around this.
Is the FILETIME struct in winapi different than that in windows.h ? If it is it means that you can never include Boost's winapi and the equivalent windows.h struct in the same TU without having a compile error. I don't think that Boost's winapi could have been designed that way.
The structure itself is binary compatible with that defined in Windows SDK. But it has a different name and is declared in the boost::detail::winapi namespace, so from the language standpoint it is a distinct type. The WinAPI functions have extern "C" linkage, which makes them have the same mangled name as the real ones in Windows SDK. If the compiler checks that C++ declarations of the similarly named extern "C" functions have the same argument types then this is a showstopper and I don't think we can do anything except to always include and use windows.h on that compiler.