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 at gmail.com>: > On 2 September 2015 at 13:01, Carl Kleffner <cmkleffner at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150902/26d500f7/attachment.html>
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