[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