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

[Ray Donnelly]

On Sun, Oct 26, 2014 at 10:41 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 26 October 2014 13:12, Tony Kelman <kelman at berkeley.edu> wrote:
>> Only cross-compilation and the build system in the above list are relevant
>> to CPython, but I hope I have convinced you, Paul Moore, etc. that there are
>> real reasons for some groups of users and developers to prefer MinGW-w64
>> over MSVC.
>
> Not really, to be honest. I still don't understand why anyone not
> directly involved in CPython development would need to build their own
> Python executable on Windows. Can you explain a single specific
> situation where installing and using the python.org executable is not
> possible (on the assumption that the mingw build is functionally
> identical and ABI compatible with the CPython build, the claim being
> made here)?

I don't know where this "ABI compatible" thing came into being; I
think Steve Dower eluded to it by stating that we should focus on
enabling MinGW-w64 as an extension-building compiler, using a core
interpreter built with MSVC, and that by limiting the interfaces to
the Windows C calling conventions everything would be OK.
Unfortunately this is not possible. MinGW-w64-built extensions need to
link to msvcrt.dll to do anything useful and you cannot mix two
different msvcr??.dlls in one application. Please see
http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=VS.100%29.aspx
and http://msdn.microsoft.com/en-us/library/ms235460%28v=VS.100%29.aspx
for the details. MinGW-w64 assumes the very old msvcrt.dll files from
Windows XP SP3 and XP64 specifically to avoid this mess. The rest of
your reply assumes that this ABI compatibility is a given so I'll stop
at this point.

> Note that "not possible" is different from "I don't want
> to" or "it doesn't fit my views about free software" or similar. Also
> note that building extensions is different - you have to assume that
> building extensions using mingw with a mingw-built CPython is just as
> hard as building them with a MSVC-built CPython (otherwise you've made
> changes to extension building and you should contribute them
> independently so that everyone can benefit, not just those who build
> their own Python with mingw!)
>
>> Paul Moore:
>>> If it were possible to cross-compile compatible extensions on Linux,
>>> projects developed on Linux could supply Windows binaries much more
>>> easily, which would be a huge benefit to the whole Windows Python
>>> community.
>>
>> I want to do exactly this in an automated repeatable way, preferably on
>> a build service. This seems harder to do when CPython cannot itself be
>> built and handled as a dependency by that same automated, repeatable
>> build service.
>
> I cannot see why you would need to build Python in order to build
> extensions. After all, if your build service is on Linux, it couldn't
> run a mingw-built Python anyway. If your build service is a Windows
> machine, just install the python.org binaries (which is a simple
> download and install, that can be fully automated, but which is a
> one-off process anyway).
>
>> Unless it becomes possible to cross-compile extensions
>> using the build machine's own version of Python, which might be the right
>> approach.
>
> This may be where we are getting confused. I see this as the only
> practical way of cross-compiling Windows extensions on Linux, by using
> the Linux Python. So being able to cross-compile Python is not
> relevant.
>
> On a tangential note, any work on supporting mingw builds and
> cross-compilation should probably be done using setuptools, so that it
> is external to the CPython code. That way (a) it isn't constrained by
> the CPython release schedules and backward compatibility constraints,
> and (b) it can be used in older versions of Python (which is pretty
> much essential if it's to be useful, TBH).
>
> Paul