There are more semantic surprises as well. Some Math functions like powf, acosf and so on are available only with the help of the VS 2015 math.h include file (32 bit case). With exporting symbols names from the universal dll's and creating import libraries you are not done yet.

Carl

2015-09-02 14:38 GMT+02:00 Paul Moore <p.f.moore@gmail.com>:
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