On 29/09/2015 00:52, Nathaniel Smith wrote:
On Mon, Sep 28, 2015 at 2:55 PM, Paul Moore <p.f.mo...@gmail.com> wrote:
On 28 September 2015 at 22:18, Nathaniel Smith <n...@pobox.com> wrote:
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.)
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
For anyone interested although this http://bugs.python.org/issue3871
mingw issue is closed, it points to four other issues. In total there
are around 25 mingw issues open. Maybe some of the work done on them
can be tied up with the work that Carl Kleffner has done?
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
_______________________________________________
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
