Base 3.16 branch fails to build on MINGW targets

[Andrew Johnson]

The build fails in src/std/rec/test when linking asTest.exe:

/usr/bin/i686-w64-mingw32-g++ -o asTest.exe -L/home/anj/Software/epics/mirror-3.16/lib/win32-x86-mingw -m32 asTest.obj asTestIoc_registerRecordDeviceDriver.obj -ldbRecStd -ldbCore -lca -lCom
asTestIoc_registerRecordDeviceDriver.obj:asTestIoc_registerRecordDeviceDriver.cpp:(.text.startup+0x37f): undefined reference to `_imp__pvar_dset_devAOasTest'
asTestIoc_registerRecordDeviceDriver.obj:asTestIoc_registerRecordDeviceDriver.cpp:(.text.startup+0x5b3): undefined reference to `_imp__pvar_dset_devWFasTest'
/usr/bin/i686-w64-mingw32-ld: asTestIoc_registerRecordDeviceDriver.obj: bad reloc address 0x5b3 in section `.text.startup'

The MinGW linker is stricter than recent versions of Microsoft Visual Studio and requires that symbols marked __declspec(dllimport) are actually imported from a DLL. Unfortunately the two device support dsets defined in asTest.c are defined locally so the linker doesn't find them, resulting in the above errors. The Microsoft linker can evidently ignore the incorrect decoration, since this file links without error on targets that use their compiler and linker. I have not tried yet, but I'm fairly confident the MINGW compiler running on Windows will fail in the same way.

The fix will involve extracting the two device support layers into their own source file and building that into a library; see src/ioc/db/test for an example that already does this.

I discovered this while cross-compiling Base-3.16 on a Linux box. I don't have a Windows cross-compiler installed on our Jenkins build slave yet or we would have seen this problem earlier — sorry!

[mdavidsaver (mdavidsaver)]

To be more specific, the failure is with SHARED_LIBRARIES = YES,
STATIC_BUILD = NO. Static builds work correctly (apparently).

A DLL build with i686-w64-mingw32-gcc 4.9.1 (Debian 8 i386) gives me an
earlier failure:

> osiClockTime.obj:osiClockTime.c:(.text+0xaa): undefined reference to `clock_settime'
> osiClockTime.obj:osiClockTime.c:(.text+0x184): undefined reference to `clock_gettime'
> osiClockTime.obj:osiClockTime.c:(.text+0x1d1): undefined reference to `clock_settime'
> osiClockTime.obj:osiClockTime.c:(.text+0x340): undefined reference to `clock_gettime'
> osiClockTime.obj:osiClockTime.c:(.text+0x38c): undefined reference to `clock_settime'

It seems that osiClockTime.c tests for posix-ness with:

> #ifdef CLOCK_REALTIME

While mingw's pthread_time.h header, which is conditionally included by
time.h, does define CLOCK_REALTIME.

> #if !defined(IN_WINPTHREAD) && \
> ((!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
> (_POSIX_C_SOURCE > 2) || defined(__EXTENSIONS__))
> #include <pthread_time.h>
> #endif

This condition looks weird since posix stuff is being included seemingly
by default. It's the only place in the public mingw headers where
_STRICT_STDC is mentioned, and it isn't defined implicitly (according to
"i686-w64-mingw32-cpp -dM"). So perhaps this is a issue w/ mingw?

https://github.com/Alexpux/mingw-w64/blob/master/mingw-w64-headers/crt/time.h#L286

[mdavidsaver (mdavidsaver)]

Was fixed some time ago.