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

Reply via email to