On Sep 28, 2015 1:39 PM, "Paul Moore" <p.f.mo...@gmail.com> wrote: > > On 28 September 2015 at 21:18, MRAB <pyt...@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.) > 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. -n
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
