[Python-Dev] Building Extensions for Python 3.5 on Windows

[Carl Kleffner]

Hi,

that is https://bugs.python.org/msg248716 see also
http://rt.openssl.org/Ticket/Display.html?id=3390&user=guest&pass=guest

Steve: is there more of that in the new universal runtimes?

Carl

2015-09-02 12:16 GMT+02:00 Paul Moore <p.f.moore at gmail.com>:

> On 1 September 2015 at 17:15, Steve Dower <steve.dower at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150902/f81fc7ac/attachment.html>