Showing content from http://mail.python.org/pipermail/python-dev/attachments/20150902/f81fc7ac/attachment.html below:
<div dir="ltr"><div><div>Hi,<br><br></div>that is <a href="https://bugs.python.org/msg248716">https://bugs.python.org/msg248716</a> see also <a href="http://rt.openssl.org/Ticket/Display.html?id=3390&user=guest&pass=guest">http://rt.openssl.org/Ticket/Display.html?id=3390&user=guest&pass=guest</a><br><br></div><div>Steve: is there more of that in the new universal runtimes?<br></div><div><br></div>Carl<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-09-02 12:16 GMT+02:00 Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 1 September 2015 at 17:15, Steve Dower <<a href="mailto:steve.dower@python.org">steve.dower@python.org</a>> wrote:<br>
> On 01Sep2015 0747, Oscar Benjamin wrote:<br>
>><br>
>> Thanks for the detailed writeup Steve. Do you know how these changes<br>
>> to the <a href="http://python.org" rel="noreferrer" target="_blank">python.org</a> Windows binaries would impact on people building<br>
>> extension modules with MinGW?<br>
><br>
><br>
> Currently, no version of MinGW AFAIK will link against the UCRT, so they'll<br>
> suffer from the same mixed-CRT issues as with any other arrangement. There<br>
> is some work going towards making mingw-w64 work with UCRT, but I am not<br>
> following it closely despite occasional contact with the dev(s) working on<br>
> it.<br>
<br>
</span>One thing that I hit when trying to build vim with VS2015 is that it<br>
appears that even compiled object code isn't linkable with the ucrt. I<br>
don't know the correct terminology here, so let me explain in a bit<br>
more detail (I'm doing this from memory, so some symbol names might be<br>
wrong, but you'll get the idea, I hope).<br>
<br>
If source code refers to FILE* objects, then previously the compiled<br>
object file (compiled with mingw) would be linkable with any of the<br>
various C runtimes (msvcrt, msvcr10, etc). The object referred to a<br>
symbol __iob_base which is present in all the CRTs. If the actual code<br>
using the library doesn't actually use any of the functions that refer<br>
to stdio, then whether the actual use of that symbol is broken doesn't<br>
(seem to) matter in practice.<br>
<br>
That's likely to be luck, to a certain extent - there's no guarantee<br>
that the internals of the FILE* abstraction are compatible between<br>
CRTs, but it has been true thus far, and so use of object libraries<br>
built with mingw are typically OK, as long as you avoid using things<br>
that need the CRT types like FILE*.<br>
<br>
But with VS 2015 and the ucrt, there is no __iob_base symbol, and so<br>
linking to code that refers to stdio fails.<br>
<br>
The consequence of this (I believe) is that not only does mingw need<br>
to be able to link against the ucrt, but it also needs to *compile*<br>
with ucrt-compatible headers. In particular, when compiling for the<br>
ucrt, mingw needs to use a version of <stdio.h> that doesn't reference<br>
__iob_base. As the mingw developers maintain their own headers by some<br>
process of "clean room" reimplementation (to satisfy the needs of the<br>
GPL, as I understand it) updating the headers to cater for the ucrt<br>
could be a non-trivial issue for them. I have no idea what their plans<br>
are in this regard.<br>
<br>
The other side of this is that it means that all object libraries you<br>
use need to be recompiled to target ucrt, you can't simply use<br>
existing compiled libraries and relink.<br>
<br>
I hope this makes sense, and my interpretation is accurate - if I've<br>
misunderstood the implications of the switch to the ucrt, then please<br>
let me know. And if I'm wrong about not being able to use existing<br>
compiled libraries, I would definitely appreciate someone telling me<br>
what I'm doing wrong, because at the moment I'm unable to build my own<br>
copy of vim with VS 2015 because I can't rebuild the xpm library :-(<br>
<br>
Paul<br>
<br>
PS My ultimate goal with building Vim with VS 2015 is to create a<br>
build that uses the new embeddable distribution of Python 3.5 to<br>
create a self-contained copy of Vim with Python 3.5 support enabled.<br>
Something I think would be awesome :-)<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com</a><br>
</div></div></blockquote></div><br></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4