[Python-Dev] Status of C compilers for Python on Windows

Victor Stinner victor.stinner at gmail.com
Fri Oct 10 11:50:09 CEST 2014


Hi,

Paul Moore wrote:
> The key point for me is that any supported build on Windows supports
> the exact same ABI.

It looks like ABI compatibility is a goal of Clang on Windows:

   http://clang.llvm.org/docs/MSVCCompatibility.html
   http://blog.llvm.org/2014/07/clangllvm-on-windows-update.html

I don't know the status of the compatibility for the C ABI with VS
2008 and VS 2010. (These articles look to be focused on C++.)


OpenWatcom and Cygwin are not compatible with VS.


Is MinGW fully compatible with MSVS ABI? I read that it reuses the
MSVCRT, but I don't know if it's enough. I guess that a full ABI
compatibility means more than just using the C library, calling
convention and much more. Clang documentation mentions for example
debug symbols compatible with the Microsoft debugger.


> ... therefore
> shared libraries compiled with one compiler won't work with the next.

I noticed this issue when I provided wheel packages for Python 2.7 and
3.3 using the same Windows SDK (7.1)...

Python 2.7 and 3.3 from python.org are built with different versions
of VS, and so require a different version of the Windows SDK (7.0 for
Python 2.7, 7.1 for Python 3.3).


> So if CPython officially said "we support MSVC and Compiler X", I worry that
> we'd have third-party modules compiled with either one or the other, leaving
> users unable to mix and match third-party extensions as they do today.

Ok, I understand and I agree. Currently, VS is the defacto standard,
at least for Python.


>  We still have #ifdef's for Borland C--I'd be very surprised if anyone was compiling Python 3 with Borland C.

I opened an issue yesterday to drop support of this compiler! Please
write your comment there to support my patch.
http://bugs.python.org/issue22592


> IMO the benefit from supporting other compilers on Windows is negligible,
> but the costs in maintaining these other compilers is tangible.  Or, worse,
> we accept changes to support these other compilers, but the support is
> incomplete, or goes unmaintained and breaks (and nobody notices).

If we decide to support officially a C compiler different than VS on
Windows, it should be a real support. It should be possible to build
Python without any patch, and we should have a buildbot. And someone
should maintain the support for this compiler (fix all bugs).

Untested code always break (later).

Victor


More information about the Python-Dev mailing list