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

Subject: Re: [boost] [winapi] Problem with the latest clang on Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-01 10:38:15

On 6/1/2015 10:07 AM, Edward Diener wrote:
> On 6/1/2015 4:02 AM, Andrey Semashev wrote:
>> On Sunday 31 May 2015 20:07:43 Edward Diener wrote:
>>> Updates to clang on Windows have broken the use of clang with the
>>> [winapi] library. I do not know if this has occurred in the past but it
>>> seems to have occurred recently when I build the latest clang from
>>> source and use it on Windows to compile build Boost libraries which use
>>> the internal winapi library.
>>>
>>> Preprocessing clang and gcc output for a given call in the Boost winapi
>>> library and in the corresponding mingw windows.h shows that both
>>> compilers view the same source but treat them differently.
>>>
>>> As an example let's look at the GetSystemTimeAsFileTime call. The
>>> preprocessed source for both clang and gcc shows:
>>>
>>> In the Boost winapi it is:
>>>
>>>        __attribute__((dllimport)) void __attribute__((__stdcall__))
>>>            GetSystemTimeAsFileTime(FILETIME_* lpFileTime);
>>>
>>> In the mingw/gcc windows.h it is:
>>>
>>>        void __attribute__((__stdcall__))
>>> GetSystemTimeAsFileTime(LPFILETIME);
>>>
>>> where the FILETIME_ and LPFILETIME are the same.
>>>
>>> When gcc sees these two declarations in the two different headers it
>>> says everything is OK.
>>>
>>> When clang sees these two declarations in the two different headers it
>>> gives an error:
>>>
>>> In file included from test_winapi.cpp:9:
>>> In file included from /mingw/include\windows.h:62:
>>> /mingw/include\winbase.h:1397:24: error: conflicting types for
>>> 'GetSystemTimeAsFileTime'
>>> WINBASEAPI void WINAPI GetSystemTimeAsFileTime(LPFILETIME);
>>>                          ^
>>> ..\..\..\boost/detail/winapi/time.hpp:70:9: note: previous declaration
>>> is here
>>>           GetSystemTimeAsFileTime(FILETIME_* lpFileTime);
>>>           ^
>>>
>>> For this line in boost/detail/winapi/time.hpp
>>>
>>>       __declspec(dllimport) void WINAPI
>>>           GetSystemTimeAsFileTime(FILETIME_* lpFileTime);
>>>
>>> It seems like the fix for clang is to leave out the
>>> __declspec(dllimport) portion of all these Boost winapi calls while
>>> leaving it in for everybody else. I am discussing this on the clang
>>> developers mailing list but it seems like they are pretty adamant that
>>> if they see __attribute__((dllimport)) in from of a function declaration
>>> and do not see it in front of another function declaration, despite the
>>> rest of the signatire being the same, the two declarations are not the
>>> same function being declared and therefore an error because of ODR.
>>
>> There's this possibly related ticket:
>>
>> https://svn.boost.org/trac/boost/ticket/11338
>>
>> 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.

With mingw64 WINBASEAPI is __attribute__((dllimport)). I will ask on the 
mingw mailing list why WINBASEAPI is empty in mingw as opposed to mingw64.

>
> I have been asked by clang to file a bug report regarding this
> situation, and wil do that.
>
>>
>> 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.