Re: [boost] [winapi] Problem with the latest clang on Windows

Subject: Re: [boost] [winapi] Problem with the latest clang on Windows
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-06-01 10:48:20

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.