We are reaching a point where our oldest supported Linux systems (and other POSIX compliant OS) have guaranteed support for clock_gettime and CLOCK_MONOTONIC, and without the need to link librt.so on Linux. All the code we have in relation to SUPPORTS_CLOCK_MONOTONIC can be unconditionalized.
There was further discussion in this thread:
# IS THIS A SAFE CHANGE for Linux?
The "clock_gettime(3) - Linux man page" says: "All implementations
support the system-wide realtime clock, which is identified by
CLOCK_REALTIME. Its time represents seconds and nanoseconds since the Epoch.". See: https://linux.die.net/man/3/clock_gettime
FYI Some older Linux ports used to implement
clock_gettime(CLOCK_REALTIME,) by calling gettimeofday() and
multiplying by 1000. This would be fine with the patch proposed, but
means that resolution would be limited to microseconds by the OS. A
Linux change 6 months ago has discouraged that in ports: "Use
clock_gettime to implement gettimeofday"
clock_gettime was already in Linux 2.6.12 (and possibly quite a bit
earlier, I did not check), so that is not likely to be a limitation.
A tricky question is whether it's possible to avoid loading librt.
The present code already uses dlopen, but I think it could try a
little bit harder (try resolving clock_gettime first, and then load
librt, and try again). For distribution builds that do not need to be
compatible with glibc versions before 2.17, directly calling
clock_gettime would also be an option. (clock_gettime moved to
libc.so.6 in glibc 2.17, but a lot of software keeps linking against
librt for the definition of clock_gettime, something that we are
finally tackling on the glibc side.)