On 1 September 2015 at 17:15, Steve Dower <steve.dower@python.org> wrote:
> On 01Sep2015 0747, Oscar Benjamin wrote:
>>
>> Thanks for the detailed writeup Steve. Do you know how these changes
>> to the python.org Windows binaries would impact on people building
>> extension modules with MinGW?
>
>
> Currently, no version of MinGW AFAIK will link against the UCRT, so they'll
> suffer from the same mixed-CRT issues as with any other arrangement. There
> is some work going towards making mingw-w64 work with UCRT, but I am not
> following it closely despite occasional contact with the dev(s) working on
> it.

One thing that I hit when trying to build vim with VS2015 is that it
appears that even compiled object code isn't linkable with the ucrt. I
don't know the correct terminology here, so let me explain in a bit
more detail (I'm doing this from memory, so some symbol names might be
wrong, but you'll get the idea, I hope).

If source code refers to FILE* objects, then previously the compiled
object file (compiled with mingw) would be linkable with any of the
various C runtimes (msvcrt, msvcr10, etc). The object referred to a
symbol __iob_base which is present in all the CRTs. If the actual code
using the library doesn't actually use any of the functions that refer
to stdio, then whether the actual use of that symbol is broken doesn't
(seem to) matter in practice.

That's likely to be luck, to a certain extent - there's no guarantee
that the internals of the FILE* abstraction are compatible between
CRTs, but it has been true thus far, and so use of object libraries
built with mingw are typically OK, as long as you avoid using things
that need the CRT types like FILE*.

But with VS 2015 and the ucrt, there is no __iob_base symbol, and so
linking to code that refers to stdio fails.

The consequence of this (I believe) is that not only does mingw need
to be able to link against the ucrt, but it also needs to *compile*
with ucrt-compatible headers. In particular, when compiling for the
ucrt, mingw needs to use a version of <stdio.h> that doesn't reference
__iob_base. As the mingw developers maintain their own headers by some
process of "clean room" reimplementation (to satisfy the needs of the
GPL, as I understand it) updating the headers to cater for the ucrt
could be a non-trivial issue for them. I have no idea what their plans
are in this regard.

The other side of this is that it means that all object libraries you
use need to be recompiled to target ucrt, you can't simply use
existing compiled libraries and relink.

I hope this makes sense, and my interpretation is accurate - if I've
misunderstood the implications of the switch to the ucrt, then please
let me know. And if I'm wrong about not being able to use existing
compiled libraries, I would definitely appreciate someone telling me
what I'm doing wrong, because at the moment I'm unable to build my own
copy of vim with VS 2015 because I can't rebuild the xpm library :-(

Paul

PS My ultimate goal with building Vim with VS 2015 is to create a
build that uses the new embeddable distribution of Python 3.5 to
create a self-contained copy of Vim with Python 3.5 support enabled.
Something I think would be awesome :-)

_______________________________________________
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/cmkleffner%40gmail.com