The reason given when this same article was discussed on reddit was that library authors need to use the same compiler as their customers. In other words, a GCC-compiled Windows DLL is not a drop-in replacement for a MSVC-compiled DLL.
I'm sure this is true for C++ which has a crazily complex ABI for things like classes and exceptions. But is this really the case for plain C? (not in the Linux world AFAIK)
x264 has worked fine in many many MSVC applications, even compiled in minGW with gcc.
There are some minor catches:
1. If you want a .lib instead of a .dll, you have to make one yourself separately using a tool. Not a big deal, it's just that gcc does do it for you.
2. No debug symbols, because MSVC doesn't support DWARF/etc.
3. gcc guarantees 16-byte stack alignment on x86_32, but only with respect to the caller; MSVC does not, so the stack may not be aligned as gcc expects it. You can use -mpreferred-stack-boundary to make gcc expect it, or you can just explicitly align the stack, either with the gcc intrinsic (requires ~gcc 4.2) or a small assembly function.
There are probably a few others, but overall, it does work; cdecl is cdecl.
C works fine, I even toyed with a kernel module build using MinGW instead of the WDK. One caveat is that GCC doesn't generate PDB information, the debugging format used by Microsoft tools.
Just as a comparison, I've heard that Oracle will most likely adopt GCC's C11 ABI when C11 support is added so that one actually will be able to mix-and-match objects from both compilers.
Pathscale compiler doesn't work on Windows, even though they claimed a beta will be relesed at some point. Clang+LLVM on Windows is very immature, I like to play with it and put it to the test once in a while but it has many problems under Windows I wouldn't trust it in production yet.
Gcc works and produces good code, unfortunately you have to deal with the disgrace that is MinGW and it doesn't integrate in Visual Studio. Most Windows developers I know care about Visual Studio integration.
The Intel compiler produces excellent code, it is C99 and Microsoft compatible, and it seaminglessly integrates with Visual Studio. Unfortunately, it's very expensive, I have never seen it used in production.
Comments
It's not that there are no alternatives..
http://gcc.gnu.org/
http://clang.llvm.org/
http://software.intel.com/en-us/intel-sdp-home/
http://www.pathscale.com/ekopath-compiler-suite
The reason given when this same article was discussed on reddit was that library authors need to use the same compiler as their customers. In other words, a GCC-compiled Windows DLL is not a drop-in replacement for a MSVC-compiled DLL.
I'm sure this is true for C++ which has a crazily complex ABI for things like classes and exceptions. But is this really the case for plain C? (not in the Linux world AFAIK)
x264 has worked fine in many many MSVC applications, even compiled in minGW with gcc.
There are some minor catches:
1. If you want a .lib instead of a .dll, you have to make one yourself separately using a tool. Not a big deal, it's just that gcc does do it for you.
2. No debug symbols, because MSVC doesn't support DWARF/etc.
3. gcc guarantees 16-byte stack alignment on x86_32, but only with respect to the caller; MSVC does not, so the stack may not be aligned as gcc expects it. You can use -mpreferred-stack-boundary to make gcc expect it, or you can just explicitly align the stack, either with the gcc intrinsic (requires ~gcc 4.2) or a small assembly function.
There are probably a few others, but overall, it does work; cdecl is cdecl.
C works fine, I even toyed with a kernel module build using MinGW instead of the WDK. One caveat is that GCC doesn't generate PDB information, the debugging format used by Microsoft tools.
Only C++ doesn't work.
Just as a comparison, I've heard that Oracle will most likely adopt GCC's C11 ABI when C11 support is added so that one actually will be able to mix-and-match objects from both compilers.
Pathscale compiler doesn't work on Windows, even though they claimed a beta will be relesed at some point. Clang+LLVM on Windows is very immature, I like to play with it and put it to the test once in a while but it has many problems under Windows I wouldn't trust it in production yet.
Gcc works and produces good code, unfortunately you have to deal with the disgrace that is MinGW and it doesn't integrate in Visual Studio. Most Windows developers I know care about Visual Studio integration.
The Intel compiler produces excellent code, it is C99 and Microsoft compatible, and it seaminglessly integrates with Visual Studio. Unfortunately, it's very expensive, I have never seen it used in production.