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).

that would certainly help, if only to set user expectations.  When
e.g. I tried to get any info from the LLVM community which macOS
versions were supposed to be still supported, it was like pulling teeth
and in the end got me nothing.  Not a particularly pleasant experience.
We should be able to do better than that.

>>> 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?

I have no idea: I donated my last alpha systems to some sort of computer
museum years ago once I had removed Tru64 UNIX support.  There are always
some enthusiasts around, some of which clamour for keeping their pet
target around a bit longer ;-)

        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Reply via email to