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 11:23:36

On 6/1/2015 10:48 AM, Andrey Semashev wrote:
> 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.

What do you mean by "discontinued" ? MingW is still around. A clang 
build targeting gcc on Windows works out of the box with MingW and not 
with MingW64. I have already discussed this on the clang developer's 
mailing list and the last response was:

"You're completely right that supporting mingw64 is better than 
supporting than mingw.org. With open source projects, someone needs to 
push http://reviews.llvm.org/D5268 through the process until commit. 
This takes time... I hope to get to this someday."

>
> 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?

I have not done it yet but when I do I will provide the link.

>
>>> 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.

What does the C++ standard say about the extern "C" declarations 
duplicating the same name as regular declarations but different types. 
Is it an ODR violation ? Maybe that is what the clang problem is about 
although gcc does not feel it is a problem seeing the exact same 
preprocessed output.