Comment 13 for bug 1853168

I fixed the ability to do MinGW DLL builds back in 2016 (6623cb01125a61ea) before the 3.14.12.6 and 3.15.5 releases, although apparently some older versions of minGW won't necessarily work. Prior to those releases our MinGW builds were configured with SHARED_LIBRARIES=NO and STATIC_BUILD=YES but that commit removed those and since they we have been doing DLL builds by default, unless you explicitly change the settings in the CONFIG_SITE.linux-x86.win32-x86-mingw and/or CONFIG_SITE.linux-x86.windows-x64-mingw files (the linux-x86_64 files inherit from those).

My version of osiClockTime.obj is not importing clock_gettime for a 7.0 build:

tux% x86_64-w64-mingw32-nm osiClockTime.obj | grep clock_gettime
tux%

However the 3.15 build does:
tux% x86_64-w64-mingw32-nm osiClockTime.obj | grep clock_gettime
                 U clock_gettime

This matches Michael's note about the 78b6312f493bbe02a37cc6f5fdcff38683d51236 commit (which evidently should have been made on an earlier branch). However my 3.15 builds here still work fine, so one of my MinGW libraries must be providing that symbol. It isn't in any of the libraries that are being linked into libCom though: -static-libgcc -static-libstdc++ -lws2_32 -ladvapi32 -luser32

However it is present in these libraries, neither of which my builds explicitly link to:

libpthread.a
00000000000000a0 T clock_gettime
libpthread.dll.a
0000000000000000 T clock_gettime
0000000000000000 I __imp_clock_gettime
libwinpthread.a
00000000000000a0 T clock_gettime
libwinpthread.dll.a
0000000000000000 T clock_gettime
0000000000000000 I __imp_clock_gettime

Can we explain what's happening there?

One solution might be to back-port the 78b6312f493bbe02a37cc6f5fdcff38683d51236 commit to 3.15, but that won't fix builds against older tagged releases. It would seem better to try and fix this in the ci-scripts module if that's possible.