On May 2, 2019, at 9:12 AM, Huw Davies huw@codeweavers.com wrote:
On Thu, May 02, 2019 at 08:55:39AM -0500, Ken Thomases wrote:
On May 2, 2019, at 3:45 AM, Huw Davies huw@codeweavers.com wrote:
+/***********************************************************************
RtlGetSystemTimePrecise [NTDLL.@]
- Get a more accurate current system time.
- RETURNS
- The current system time.
- */
+LONGLONG WINAPI RtlGetSystemTimePrecise( void ) +{
- LONGLONG time;
+#if defined(HAVE_CLOCK_GETTIME)
- struct timespec ts;
- if (!clock_gettime( CLOCK_REALTIME, &ts ))
- {
time = ts.tv_sec * (ULONGLONG)TICKSPERSEC + TICKS_1601_TO_1970;time += (ts.tv_nsec + 50) / 100;- }
- else
+#endif
Using clock_gettime() on macOS is a bit problematic because of backward deployment and weak linking. See <https://source.winehq.org/git/wine.git/commit/27c71e09ad51ba6aa672a46379efd1... although that's not necessarily my preferred approach. (I wanted to check if it was available at run-time and use it, if so. Alexandre didn't like that.)
Gah, how annoying! Perhaps we should disable the HAVE_CLOCK_GETTIME configure test on macOS in that case?
Perhaps we could try to detect if it's strong linked or weak linked in the configure test. It will be strong linked if the deployment target is guaranteed to have it.
One way would be to check the output of "nm -m conftest.o" for "weak .* _clock_gettime" or so.
Another would be to compile code with "if (clock_gettime == NULL) …" with "-Werror=tautological-pointer-compare". If that fails, then it's strong linked. If it gets no error, then it's weak linked.
-Ken