Comment 1 for bug 1869751

commit 4b8b84cce1fd57eec1f47ca44780d60c148b399d
Author: Jan Pokorný <email address hidden>
Date: Fri Nov 15 16:06:57 2019 +0100

    Build: restore buildability in the face of obsolete ftime(3)

    Since the usage of ftime(3) is purely optional and since
    clock_gettime(3) is mandated with POSIX 2001, we can simply
    look at whether CLOCK_MONOTONIC is defined to be used as an
    identifier for the particular clock (kind exactly suitable
    for this context). But due to being late in the release cycle,
    such a change is kept as opt-in (see configure.ac comment for
    details), and for compatibility stability concerns[*], also
    dropping some old surrounding cruft is delayed.

    In this form, constitutes first step out of two to restore
    out-of-the-box buildability with recent enough glibc, again,
    refer to configure.ac comment.

    References:
    https://sourceware.org/git/?p=glibc.git;a=commit;h=2b5fea833bcd0f651579afd16ed7842770ecbae1
    https://src.fedoraproject.org/rpms/glibc/c/ebf75398f06dd27357d8a5321e8e5959633b8182?branch=master
    (for a Fedora Rawhide follow-the-upstream update that led to this
    discovery)

    [*] in case you opt-in (as described), CLOCK_MONOTONIC gets detected
        in time.h positively but it starts choking for whatever reason in
        the actual build or even in run-time, you can rescind that,
        or you can shortcut any checking and refrain from any time period
        measurements altogher with something like:

          env \
            ac_cv_header_sys_timeb_h=no
            ac_cv_have_decl_CLOCK_MONOTONIC=no \
            ./configure