You can also build existing object or static libraries into their own DLL with the old compiler and dynamically link to them. It's not perfect, but it's no worse than trying to link them in directly. Otherwise, your analysis is correct. The OpenSSL issue was because they directly referred to __iob_func in their own code. It submitted a patch for it months ago and they fixed it, but possibly only in 1.0.2. Cheers, Steve Top-posted from my Windows Phone -----Original Message----- From: "Paul Moore" <p.f.moore@gmail.com> Sent: 9/2/2015 5:38 To: "Carl Kleffner" <cmkleffner@gmail.com> Cc: "Steve Dower" <steve.dower@python.org>; "Python Dev" <python-dev@python.org> Subject: Re: [Python-Dev] Building Extensions for Python 3.5 on Windows On 2 September 2015 at 13:01, Carl Kleffner <cmkleffner@gmail.com> wrote:
that is https://bugs.python.org/msg248716 see also http://rt.openssl.org/Ticket/Display.html?id=3390&user=guest&pass=guest
Interesting. But it does confirm that object files have to be rebuilt, and there's no way to use existing object files. So if your source only builds with mingw, it needs mingw's headers updating before you can do that rebuild. FWIW, in the case I hit with xpm, the xpm library only uses FILE* internally - the external APIs are purely in terms of filenames. And it only uses FILE* via the standard C APIs for it. So it's not a simple case of "avoid using CRT types in external APIs". So unless I'm misunderstanding, *any* object code used in a project (whether directly or from a 3rd party library) has to be build using a compiler that supports the ucrt (which, given that mingw doesn't have that support yet, means VS 2015 only). Note: I understand why the move to the ucrt is good, and I view this as very much a short term transitional issue, but it is real and I think it's important people understand the implications. Paul