[Python-Dev] VS 2010 compiler

[Nathaniel Smith]

On Mon, Sep 28, 2015 at 2:55 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 28 September 2015 at 22:18, Nathaniel Smith <njs at pobox.com> wrote:
>> On Sep 28, 2015 1:39 PM, "Paul Moore" <p.f.moore at gmail.com> wrote:
>>>
>>> On 28 September 2015 at 21:18, MRAB <python at mrabarnett.plus.com> wrote:
>>> > Same here. I compile the regex module for Python 2.5-2.7 and 3.1-3.5,
>>> > both 32-bit and 64-bit, using MinGW-w64, and I haven't had a problem yet
>>> > that wasn't due to a bug in the source code.
>>>
>>> Interesting. With Python 3.5, what CRT does the module use? With
>>> Python 3.4 and earlier, distutils arranged for mingw builds to link to
>>> the CRT that matched the CPython build,
>>
>> This doesn't sound right to me. Maybe if you're talking about the original
>> mingw, but that's been abandoned upstream for years. Nowadays everyone uses
>> the mingw-w64 fork, for both 32 and 64 bits. And in mingw-w64, the only way
>> to select a non-default CRT is to hack up the toolchain's source tree and
>> cross your fingers. It's definitely not a supported configuration upstream.
>> (Source: we've been talking to mingw-w64 upstream and MS about how to
>> potentially make building free software less painful on Windows.)
>
> Interesting, it's been a long time since I've done work on the mingw
> support, so I hadn't realised this had happened.
>
> I guess that means that nowadays all mingw-compiled extensions link to
> msvcrt (I assume that's still the CRT that mingw-w64 uses by default)?

Right, linking to msvcrt.dll is the only standard/supported
configuration for upstream mingw-w64.

>>> but I don't think that
>>> happened for 3.5 (because mingw doesn't support ucrt yet). So you'd
>>> have a CRT that doesn't match the core. Obviously this isn't causing
>>> you issues, but I'm not sure if it could (CRT problems seem to be
>>> mostly about "might cause issues" type problems...)
>>
>> CRT issues are indeed tricky, because they only bite in certain
>> circumstances -- so long as you never pass a FILE* or a fileno across the
>> dll boundary, or call malloc in one module and free in the other, or ...
>> then it works fine. Except when it doesn't :-).
>>
>> Example of a subtle issue: msvc and mingw-w64 disagree about whether the x87
>> fpu should be configured in extended precision mode or not. So simply
>> loading a mingw-w64-compiled dll can potentially cause math functions in
>> other dlls to start returning incorrect results. Or maybe not -- it depends
>> on the details of how MS implemented things, and we can't exactly check. Or
>> whether you get correct math result in mingw-w64 compiled code can depend on
>> which runtime was used to spawn the thread that's running the code (!!). And
>> even if things work today, it could change without warning in any update,
>> because no one is testing this configuration upstream.
>>
>> It's totally plausible that the regex module happens to avoid all these
>> issues. But you can't assume that it's a general solution.
>
> Agreed. That was essentially what I was asking - has someone found a
> solution to the issue of avoiding mixed CRTs when using mingw as a
> compiler (or at least, found a better solution than using the original
> mingw -lmsvcr100 approach combined with the distutils code that
> supports this). Looks like the answer is that nobody has. But it's
> certainly (still) true that for straightforward cases things seem
> pretty much OK, especially if you avoid the "obvious" issues. (The
> non-obvious ones sound terrifying, and I'm glad I don't have to write
> code that encounters those!!!)

It's not *quite* "nobody has". Carl Kleffner has been doing a lot of
work on trying to set up Python-compatible gcc-based toolchains for
Windows. (This is still pretty much the only hope for getting a usable
free fortran compiler on Windows, and there's still lots of fortran
down at the bottom of the scientific/numerical stack). It's still
rather beta and the approach probably isn't sustainable without more
funding, but right now it's probably the closest thing you can get to
what you're asking about. I believe these are the latest builds:

https://binstar.org/carlkl/mingwpy/files

(Yes, those are .whl files that contain compiler toolchains.)

(Also, if making this *actually* work reliably would make a difference
to anyone, then feel free to send me heartfelt testimonials and I'll
forward them on to MS. Or I guess you could just send them to Steve
Dower directly ;-).)

-n

-- 
Nathaniel J. Smith -- http://vorpus.org