[Python-Dev] VS 2010 compiler

[Paul Moore]

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)?

>> 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!!!)

Cheers,
Paul