4 ms·

> if your project is Windows-only, you can get a second compiler’s opinion on your code, and Clang’s warnings might find bugs GCC (mingw.org and mingw-w64 trip

by tavert 9y ago

> if your project is Windows-only, you can get a second compiler’s opinion on your code, and Clang’s warnings might find bugs GCC (mingw.org and mingw-w64 triples) has existed and been able to do this, including and especially cross-compiling, for a long time. No need to manually download a Windows SDK either. edited to add: to be fair, it's not ABI compatible with MSVC. But it deserves a mention and it's an easier option than MSVC-style build systems for many open source projects.

bedros 9y ago
Apple hired developers of Clang and started supporting Clang around the time GPLv3 was being pushed by FSF, Apple at the time was using GCC in their development and feared that GPLv3 would taint their code. other than technical merits, permissible license of Clang is attractive for some developers/businesses
- kccqzy 9y ago
  I thought Apple didn’t just “hire” the developers of clang. They started the clang project in-house before eventually open sourcing it.
  - gsnedders 9y ago
    Yes; Clang was started internally to Apple. They did "just hire" the developer of LLVM.
gsnedders 9y ago
> edited to add: to be fair, it's not ABI compatible with MSVC. But it deserves a mention and it's an easier option than MSVC-style build systems for many open source projects. Pretty sure this is significant in Chrome's case.
- saurik 9y ago
  Why, though? What does Chrome do that calls into C++ code compiled by anyone but Google?
  - valarauca1 9y ago
    on Windows the native ABI (or the default ABI I should say) explicitly reserves space for C++ stack unwinding on a per call basis. A lot of the windows API can (ab)use this so it’s best to follow it, despite it being C (ish).
  - gsnedders 9y ago
    File dialogs (to save/load web pages, to upload files), print support, TCP sockets… all of these involve calling into system code.
    - tavert 9y ago
      do any of those require ABI compatibility at the C++ level? win32 API's are generally exposed as C
      - Const-me 9y ago
        > win32 API's are generally exposed as C A lot of newer Win32 APIs are IUnknown-based COM interfaces. APIs that are probably relevant for Chrome are shell interop, drag & drop, Direct2D, Direct Write, Media Foundation.
brucedawson 9y ago
Does this option give you full debug information? My impression was that it does not. I require full debug information for debugging and profiling, and with clang-cl I get that (context: I work on Chromium)
- chandlerc1024 9y ago
  My memory is that it supports DWARF debug info. So you get full debug info in DWARF and can use the mingw port of GDB on Windows. Still, this is very different from the first-class support for compatible debug info that Clang provides.
mappu 9y ago
One of mingw{,-w64}'s major contributions is a gcc-compatible replacement set of headers and import libraries, instead of using the Windows SDK or MSVC versions. These work great most of the time, but if you start hooking deeply into windows, you realise they are a little bit outdated or incompatible. e.g. I get a lot of errors like #warning COM interfaces layout in this header has not been verified. #warning COM interfaces with incorrect layout may not work at all. #pragma message: Interface Ifoo has unverified layout. in COM code, and some ATL things it is unable to build at all.
martell 9y ago
mingw-w64 llvm maintainer/developer here. Over the past 2-3 years, with great help from a few other LLVM devs I have slowly pushed for native clang support for mingw-w64. With the current in tree HEAD you can now build and bootstrap mingw-w64 with a llvm-only toolchain (no binutils or gcc, thus no disregard of the PECOFF SPEC) The stack is as follows. LLVM+CLANG+LLD+COMPILER-RT+LIBCXX+LIBCXXABI+LIBUNWIND+MINGW-W64. The libraries and executables built this way can be dropped into visual studio quite easily, the two environments are now basically interchangeable. This also means we can borrow the PDB debugging work by Zachary Turner and/or any msvc features added to llvm for free that was done by the various googlers working on chrome. See a talk from Reid on the most recent LLVM developer meetup for more info on PDB and how it works. There has been no formal release of this environment yet but you should see something in the coming weeks/months. I keep build scripts here for those interested. https://github.com/martell/mingw-w64-clang https://github.com/martell/mingw-w64-clang I'm due another cleanup of the repo now that wine 3.0 is out so I can actually run x64 tests within a linux docker container. I'm going to be doing some blogging to make this more visible with various partners that want to support this. The most interesting part of this for me was implementing a llvm-dlltool alternative to binutils dlltool that actually works within the PECOFF spec so msvc lib.exe and link.exe likes what it produces. https://reviews.llvm.org/rL308379 https://reviews.llvm.org/rL308379
- zturner 9y ago
  This sounds great, it's been a long time coming and I'm sure many people will appreciate being able to debug their mingw generated executables in Visual Studio. I did all of the PDB stuff in LLVM, happy to help if you need it (ping me on the mailing list or IRC)
  - martell 9y ago
    Updated the comment to reflect this. :) Thanks for all the good work. Will ping you when I move onto that stage for support.
- brucedawson 9y ago
  I've been watching the process of getting git to build with VS, but it's sounding like mingw-w64 will gain PDB output faster than the VS version will happen. Either way, if I can debug (and profile) git.exe then I'm happy.

by tavert 9y ago

bedros 9y ago

Apple hired developers of Clang and started supporting Clang around the time GPLv3 was being pushed by FSF, Apple at the time was using GCC in their development and feared that GPLv3 would taint their code. other than technical merits, permissible license of Clang is attractive for some developers/businesses

kccqzy 9y ago
I thought Apple didn’t just “hire” the developers of clang. They started the clang project in-house before eventually open sourcing it.
- gsnedders 9y ago
  Yes; Clang was started internally to Apple. They did "just hire" the developer of LLVM.

gsnedders 9y ago

> edited to add: to be fair, it's not ABI compatible with MSVC. But it deserves a mention and it's an easier option than MSVC-style build systems for many open source projects. Pretty sure this is significant in Chrome's case.

saurik 9y ago
Why, though? What does Chrome do that calls into C++ code compiled by anyone but Google?
- valarauca1 9y ago
  on Windows the native ABI (or the default ABI I should say) explicitly reserves space for C++ stack unwinding on a per call basis. A lot of the windows API can (ab)use this so it’s best to follow it, despite it being C (ish).
- gsnedders 9y ago
  File dialogs (to save/load web pages, to upload files), print support, TCP sockets… all of these involve calling into system code.
  - tavert 9y ago
    do any of those require ABI compatibility at the C++ level? win32 API's are generally exposed as C
    - Const-me 9y ago
      > win32 API's are generally exposed as C A lot of newer Win32 APIs are IUnknown-based COM interfaces. APIs that are probably relevant for Chrome are shell interop, drag & drop, Direct2D, Direct Write, Media Foundation.

brucedawson 9y ago

Does this option give you full debug information? My impression was that it does not. I require full debug information for debugging and profiling, and with clang-cl I get that (context: I work on Chromium)

chandlerc1024 9y ago
My memory is that it supports DWARF debug info. So you get full debug info in DWARF and can use the mingw port of GDB on Windows. Still, this is very different from the first-class support for compatible debug info that Clang provides.

mappu 9y ago

One of mingw{,-w64}'s major contributions is a gcc-compatible replacement set of headers and import libraries, instead of using the Windows SDK or MSVC versions. These work great most of the time, but if you start hooking deeply into windows, you realise they are a little bit outdated or incompatible. e.g. I get a lot of errors like #warning COM interfaces layout in this header has not been verified. #warning COM interfaces with incorrect layout may not work at all. #pragma message: Interface Ifoo has unverified layout. in COM code, and some ATL things it is unable to build at all.

martell 9y ago

mingw-w64 llvm maintainer/developer here. Over the past 2-3 years, with great help from a few other LLVM devs I have slowly pushed for native clang support for mingw-w64. With the current in tree HEAD you can now build and bootstrap mingw-w64 with a llvm-only toolchain (no binutils or gcc, thus no disregard of the PECOFF SPEC) The stack is as follows. LLVM+CLANG+LLD+COMPILER-RT+LIBCXX+LIBCXXABI+LIBUNWIND+MINGW-W64. The libraries and executables built this way can be dropped into visual studio quite easily, the two environments are now basically interchangeable. This also means we can borrow the PDB debugging work by Zachary Turner and/or any msvc features added to llvm for free that was done by the various googlers working on chrome. See a talk from Reid on the most recent LLVM developer meetup for more info on PDB and how it works. There has been no formal release of this environment yet but you should see something in the coming weeks/months. I keep build scripts here for those interested. https://github.com/martell/mingw-w64-clang https://github.com/martell/mingw-w64-clang I'm due another cleanup of the repo now that wine 3.0 is out so I can actually run x64 tests within a linux docker container. I'm going to be doing some blogging to make this more visible with various partners that want to support this. The most interesting part of this for me was implementing a llvm-dlltool alternative to binutils dlltool that actually works within the PECOFF spec so msvc lib.exe and link.exe likes what it produces. https://reviews.llvm.org/rL308379 https://reviews.llvm.org/rL308379

zturner 9y ago
This sounds great, it's been a long time coming and I'm sure many people will appreciate being able to debug their mingw generated executables in Visual Studio. I did all of the PDB stuff in LLVM, happy to help if you need it (ping me on the mailing list or IRC)
- martell 9y ago
  Updated the comment to reflect this. :) Thanks for all the good work. Will ping you when I move onto that stage for support.
brucedawson 9y ago
I've been watching the process of getting git to build with VS, but it's sounding like mingw-w64 will gain PDB output faster than the VS version will happen. Either way, if I can debug (and profile) git.exe then I'm happy.