On 17/11/20 14:25 +0100, Rainer Orth wrote:
Hi Jonathan,

There are two more uses of librt left:

* On glibc targets before 2.17 it's needed for clock_gettime.  I've no
 idea how long gcc is supposed to support such targets (glibc 2.17 was
 released in December 2012).

RHEL 7 uses glibc 2.17, so it will still be in use for some time.

but at least the comments say < 2.17, so RHEL 7 wouldn't be affected.

Ah right, sorry, I read too quickly. Yes, < 2.17 probably isn't very
relevant now, although historically libstdc++ has not explicitly
dropped support older glibc versions. If it builds, then it builds.

We could consider doing some housekeeping in that area, or just
documenting our requirements more carefully (for example, we now
require Linux kernel version 2.6.22 for the FUTEX_PRIVATE_FLAG but I
don't think we say that anywhere).

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -1381,8 +1381,8 @@ dnl
dnl --enable-libstdcxx-time
dnl --enable-libstdcxx-time=yes
dnl        checks for the availability of monotonic and realtime clocks,
-dnl        nanosleep and sched_yield in libc and libposix4 and, if needed,
-dnl        links in the latter.
+dnl        nanosleep and sched_yield in libc and, if needed, links in the
+dnl        latter.

"The latter" was referring to libposix4, and we always link to libc,
so "if needed" doesn't apply to it.

So I think it should be:

 dnl        checks for the availability of monotonic and realtime clocks,
-dnl        nanosleep and sched_yield in libc and libposix4 and, if needed,
-dnl        links in the latter.
+dnl        nanosleep and sched_yield in libc.



diff --git a/libstdc++-v3/doc/xml/manual/configure.xml
b/libstdc++-v3/doc/xml/manual/configure.xml
--- a/libstdc++-v3/doc/xml/manual/configure.xml
+++ b/libstdc++-v3/doc/xml/manual/configure.xml
@@ -171,7 +171,7 @@
        <function>sched_yield</function> functions, used in the
        implementation of [thread.thread.this] of the 2011 ISO C++ standard.
        The choice OPTION=yes checks for the availability of the facilities
-       in libc and libposix4.  In case it's needed the latter is also linked
+       in libc.  In case it's needed the latter is also linked
        to libstdc++ as part of the build process.  OPTION=rt also checks in

Similarly, the whole "In case it's needed the latter is also linked to
libstdc++ as part of the build process." sentence should be removed. It
only applied to libposix4.

Good catch: I've been too mechanical in my updates.  Btw., can you take
care of regenerating the html files there?

Yes, no problem.

        librt (and, if it's needed, links to it).  Note that linking to librt
        is not always desirable because for glibc it requires linking to

The libstdc++ part is OK with those adjustments. Thanks for doing
this, it's really helpful to trim these checks so the unnecessary
parts don't hang around indefinitely.

My pleasure: they are easy enough to miss, unfortunately, since the are
seldom labeled with `for OS version X.Y' or some such.  E.g. we still
have a libexc test in gcc/configure.in, which was only added for Tru64
UNIX, I believe (unless Linux/alpha needs it, too).

Do we even have anybody still using alpha?


Reply via email to