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:07:56

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.

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.