[cfe-dev] Windows headers that are troublesome for clang

James Gregurich bayoubengal at mac.com
Tue Aug 26 21:10:29 PDT 2014

On Aug 26, 2014, at 10:50 PM, Nikola Smiljanic <popizdeh at gmail.com> wrote:

> I'm not sure if this has changed since clang-cl was introduced but resulting clang depends on what you build it with. I'm sure this will go away at some point if it hasn't already. Compiling clang with mingw produces a mingw compatible clang that uses libstd++ and ld. Compiling it with Visual Studio would produce msvc compatible clang that uses msvc stl and link.exe. I think the main difference comes from the triple where something like i586-win32-pc defines a different abi from i586-pc-mingw and passes -fms-extensions -fms-compatibility and some other stuff to indicate msvc compatibility. Have a look at http://clang.llvm.org/docs/MSVCCompatibility.html
> clang-cl is supposed to be a drop in replacement for cl.exe and as such accepts same command line options and enables language extensions and/or bugs :). The same way clang/clang++ are a drop in replacement for gcc/g++. But there's nothing preventing you from using the compliant version of clang on windows, it's just a matter of what flags are being passed to the driver.
> Then there's also the idea of the complete clang toolchain on windows (libc++, lld, lldb) that many people would like to use. But the question of default ABI for this toolchain still remains. I can't find the thread but I remember someone pointing out that just because Microsoft owns the platform it doesn't mean that their compiler's abi should be seen as the default one. But if Herb's proposal for C++ ABI is accepted it will mean exactly that, the platform defines the abi... 

What I would hope is possible is to be able to specify on a per-translation-unit basis to compile the unit in a completely normal fashion, but get microsoft symbols in the .o files OR compile the unit with with the microsoft-spcific adaptations. That way, some units could depend on Windows.h and Win32 and others could depend on libc++ and behave as I would expect on every other platform. If I can do that then I can contrive a shim layer to adapt insulated Win32 code to work with any standard c++ code that I want. 

I always structure my projects so that most of it is standard c++ with an insulated platform-specific later…even if I don’t immediately need to have the code cross-platform.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140826/65a238a3/attachment.html>

More information about the cfe-dev mailing list