Hi Mateusz,
On 1/2/19 5:45 PM, Mateusz wrote:
W dniu 02.01.2019 o 16:32, JonY via Mingw-w64-public pisze:
On 1/2/19 1:10 PM, Johannes Pfau wrote:
Hello all,
I'm currently adding (some basic) MinGW support to the D code which
was recently merged into GCC9. The D runtime library already has full
windows support, developed by DMD and LLVM D compiler devs. However,
this needs MSVC runtime versions >= 120. So I'm now trying to add
proper support for targeting newer MSVC libs to the GCC/MinGW ecosystem.
It turns out libgomp uses _ftime, but this symbol is only exposed for
msvcrt.dll and I get linker errors for any other MSVC version.
Therefore this patch adds the _ftime aliases to all msvcr .def
files. According to timeb.h, there should be a _ftime symbol which
maps to _ftime64 on _WIN64 and _ftime32 for anything else.
This is my first MinGW patch, so please feel free to point out if
there's anything wrong with the patch.
BTW: How do you handle branches for the patches? The attached patch
is against the v6.x branch.
Best regards,
Johannes
Ideally, the patch should be against master, and then cherry-picked to
v6.x. If there are conflicts, please prepare the patch for both branches.
I'll let LH, Jacek and the others comment on the patch.
On
pagehttps://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/ftime-ftime32-ftime64?view=vs-2017
there is an example program.
I've tested this example in 64-bit GCC msvcrt/msvcr120/ucrtbase + 32-bit GCC
msvcrt/msvcr120/ucrtbase -- all works. Could you specify example that not works?
Note that in this example, a header file is used and it's redirected in
header file itself by a macro (like we do). The patch affects importlib
entries. To test them you could for example declare the function yourself.
Thanks,
Jacek
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public