Re: [PATCH] ada: c++: Get rid of libposix4, librt on Solaris
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
Re: [PATCH] ada: c++: Get rid of libposix4, librt on Solaris
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 dnlchecks for the availability of monotonic and realtime clocks, -dnlnanosleep and sched_yield in libc and libposix4 and, if needed, -dnllinks in the latter. +dnlnanosleep and sched_yield in libc and, if needed, links in the +dnllatter. "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: dnlchecks for the availability of monotonic and realtime clocks, -dnlnanosleep and sched_yield in libc and libposix4 and, if needed, -dnllinks in the latter. +dnlnanosleep 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 @@ sched_yield 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?
Re: [PATCH] ada: c++: Get rid of libposix4, librt on Solaris
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. >>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 >> dnlchecks for the availability of monotonic and realtime clocks, >>-dnlnanosleep and sched_yield in libc and libposix4 and, if needed, >>-dnllinks in the latter. >>+dnlnanosleep and sched_yield in libc and, if needed, links in the >>+dnllatter. > > "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: > > dnlchecks for the availability of monotonic and realtime clocks, > -dnlnanosleep and sched_yield in libc and libposix4 and, if needed, > -dnllinks in the latter. > +dnlnanosleep 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 @@ >> sched_yield 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? >> 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). Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] ada: c++: Get rid of libposix4, librt on Solaris
On 17/11/20 10:47 +0100, Rainer Orth wrote: I recently noticed that neither libposix4 nor librt are needed on Solaris 11 any longer: * libposix4 was renamed to librt in Solaris 7 back in 1998. * librt was folded into libc in the OpenSolaris timeframe, leaving librt only as a filter on libc. Thus, it's no longer needed on either Solaris 11 or Illumos. The following patch removes both uses. At the same time, Ada's use of libthread has gone: it was folded into libc in Solaris 10 already. TIME_LIBRARY and friends in g++ are likewise removed: Solaris was the only user. Bootstrapped without regressions on i386-pc-solaris2.11, sparc-sun-solaris2.11, and x86_64-pc-linux-gnu. Ok for master? 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. 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 dnlchecks for the availability of monotonic and realtime clocks, -dnlnanosleep and sched_yield in libc and libposix4 and, if needed, -dnllinks in the latter. +dnlnanosleep and sched_yield in libc and, if needed, links in the +dnllatter. "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: dnlchecks for the availability of monotonic and realtime clocks, -dnlnanosleep and sched_yield in libc and libposix4 and, if needed, -dnllinks in the latter. +dnlnanosleep 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 @@ sched_yield 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. 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.
Re: [PATCH] ada: c++: Get rid of libposix4, librt on Solaris
> I recently noticed that neither libposix4 nor librt are needed on > Solaris 11 any longer: > > * libposix4 was renamed to librt in Solaris 7 back in 1998. > > * librt was folded into libc in the OpenSolaris timeframe, leaving librt > only as a filter on libc. Thus, it's no longer needed on either > Solaris 11 or Illumos. > > The following patch removes both uses. At the same time, Ada's use of > libthread has gone: it was folded into libc in Solaris 10 already. > TIME_LIBRARY and friends in g++ are likewise removed: Solaris was the > only user. > > Bootstrapped without regressions on i386-pc-solaris2.11, > sparc-sun-solaris2.11, and x86_64-pc-linux-gnu. > > Ok for master? The Ada part is OK, thanks. > 2020-11-16 Rainer Orth > > gcc/cp: > * g++spec.c (TIMELIB, TIME_LIBRARY): Remove. > (lang_specific_driver): Remove TIME_LIBRARY handling. > > gcc: > * config/sol2.h (TIME_LIBRARY): Remove. > > libstdc++-v3: > * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Remove libposix4 > references. > : Don't use -lrt any longer. > * configure: Regenerate. > > * doc/xml/manual/configure.xml (--enable-libstdcxx-time=OPTION): > Remove libposix4 reference. > > gcc/ada: > * Makefile.rtl (THREADSLIB): Remove. > (MISCLIB): Remove -lposix4. > <*86-*-solaris2*>: Likewise. > * libgnarl/s-osinte__solaris.ads (System.OS_Interface): Remove > -lposix4 -lthread.
