On 5/31/2015 8:44 PM, Niall Douglas wrote:
On 31 May 2015 at 20:07, Edward Diener wrote:
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.
Oddly enough this topic came up at C++ Now when I was chatting with Chandler.
They are immovable on clang being standards conformant in mingw mode. That means API declarations must match. Else it's a bug, and it will be errored out. Just because MSVC uses sloppy declspec doesn't mean it's valid C++. They will not back down, or change their mind on this, period.
Evidently from my OP it is gcc being sloppy.
Switching clang into msvc mode makes everything just work.
Clang in MSVC mode means you're dealing with a compiler trying to emulate a broken preprocessor. No thanks ! I already had this discussion on the clang mailing lists and since they are adamant that they must attempt to emulate the VC++ preprocessor bugs in all situations I will not use that mode. I suggested to them a system by which they could emulate the broken VC++ preprocessor for VC++ headers which need it and otherwise support a C++ standard compliant preprocessor everywhere else, but they did not want to consider it. So it doesn't make everything just work. In fact it may break any Boost library which uses Boost PP. And that's not a problem which Boost PP is going to try to solve. Boost build also doesn't have built-in support for clang in VC++ mode on Windows but works fine with clang in gcc mode on Windows.
For reference. Boost.Thread no longer compiles at all on clang in mingw mode for the same reason, but nearly gets there with clang in msvc mode. I suspect plenty more libraries are similar. At some point we'll need to go fix up all our code.
If we fix up Boost win32 we might be OK. That was the gist of my OP.