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 21:49:08

On 6/1/2015 9:11 PM, Niall Douglas wrote:
> On 2 Jun 2015 at 1:57, Andrey Semashev wrote:
>
>> Since other than the above there are no special treatment of extern "C"
>> function calls from the language perspective, I would assume that as long as
>> the call in unambiguous by the C++ overload resolution rules, the language
>> should allow it.
>>
>> If clang folks say this should not compile then perhaps they could point to
>> the relevant part of the standard.
>
> Obviously declspec anything is non-standard.
>
> I believe the reason clang is insisting on this behaviour is because
> declspec is part of the type definition. You can see this in how
> pointers to functions retain their declspec attributes in the pointer
> type.
>
> Therefore not always specifying them consistently is an ODR
> violation, and therefore clang is being right here. GCC matches
> MSVC's incorrectness here for ease of life. As does clang when in
> MSVC mode.
>
> Regarding mingw's broken headers which don't specify dllimport
> correctly for kernel32 imports, yeah that's one of a long litany of
> problems in mingw's headers. I in fact gave up on mingw support in
> AFIO in the v1.3 release, it was becoming too painful to keep working
> around their severe quality problems. AFIO now only supports
> mingw-w64.
>
> Mingw-w64 have done an excellent job, and are light years ahead of
> mingw in quality control and stability. They also support the C++ 11
> <thread> header, which mingw does not.

I agree that mingw64 is much better but clang can only target gcc from 
mingw, and not mingw64, without alot of hacking I am not in the mood to 
try. In order to run clang on Windows using bjam to test Boost library 
code I have to build clang targeting mingw/gcc. There is no other choice 
unless clang provides mingw64/gcc as a possible target.

>
> Regarding why clang is not on mingw-w64 yet, apparently it may be
> political. See
> http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/873
> 8aihlgy.fsf_at_[hidden]/.

That does not appear to be apropos the issue of building clang with 
mingw64/gcc. Instead it appears to be about using clang to create 
mingw64 builds. Did I miss something in that discussion ?

> I agree with the assessment that mingw
> support is not a priority for the clang devs compared to MSVC
> support, but I am not aware of any active campaign against mingw-w64
> support. It's more no one could be bothered relative to other things
> to do I think.

As explained before the current MSVC build of clang is absolutely 
useless for testing Boost, unless you are not using Boost PP at all. 
Which is fine but many libraries are for a good reason.

>
> Anyway, from my own perspective whilst it would be nice if
> mingw-clang was working, it's no showstopper for me personally. MinGW
> users are a tiny proportion of the user base, sufficiently tiny that
> GCC is good enough for now. I see mingw-w64 is very shortly going to
> release a GCC 5.1 build, it's hardly like MinGW users are suffering
> from ancient GCC tooling or something.

I also test gcc on Windows using mingw64. It works very nicely. But it 
is good to try clang also with Boost libraries. Despite what you may 
believe both gcc and clang are better C++ standard conformant compilers 
than even the most recent VC++13 version. That's not to say I haven't 
used VC++ extensively in corporate consulting jobs. I have and it has 
done the job for the type of programming corporations desire. But if you 
are talking about adherence to the C++ standard VC++ has always been 
behind, never mind the broken preprocessor.

>
> winclang is a whole different beast though. That's an enormous threat
> to MSVC in the medium term. Microsoft may, of course, just go ahead
> and bundle a winclang toolset in future Visual Studios as an equally
> supported alternative to MSVC. That would be *enormous* for anyone
> trying to do modern C++ on Windows, though MSVC is coming along
> hugely of late and it's still vastly faster to compile than clang,
> and I suspect always will be.

The slow compilation speed of clang has been also discussed on their 
developers mailing list. But that's not a showstopper.

>
> Niall