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.mo...@gmail.com>: > On 1 September 2015 at 17:15, Steve Dower <steve.do...@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 >
_______________________________________________ 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
