diff mbox series

Let libstdc++ know that VxWorks has_nanosleep

Message ID C4992368-E7DB-425A-B7A0-CAE46376BB89@adacore.com
State New
Headers show
Series Let libstdc++ know that VxWorks has_nanosleep | expand

Commit Message

Olivier Hainque Dec. 13, 2019, 5:54 p.m. UTC 
This change adjusts the libstdc++ configuration for VxWorks
to set ac_has_nanosleep=yes, which enables the use of nanosleep
from the library.

While this technically depends on the kernel configuration
(INCLUDE_POSIX_TIMERS) this is the normal configuration in all
the environments we have been given to work with for the past
decade and activating this improves the library in our experience.

Tested in accordance with the description in
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00911.html

Best Regards,

Olivier

2019-12-13  Corentin Gay  <gay@adacore.com>

	libstdc++/
	* acinclude.m4 (vxworks*): New entry. Set ac_has_nanosleep=yes.
	* configure: Regenerate.

Comments

Jonathan Wakely Dec. 19, 2019, 11:13 a.m. UTC | #1 
On 13/12/19 18:54 +0100, Olivier Hainque wrote:
>
>This change adjusts the libstdc++ configuration for VxWorks
>to set ac_has_nanosleep=yes, which enables the use of nanosleep
>from the library.
>
>While this technically depends on the kernel configuration
>(INCLUDE_POSIX_TIMERS) this is the normal configuration in all
>the environments we have been given to work with for the past
>decade and activating this improves the library in our experience.

Is there a way to detect that more reliably? Should we replicate the
test used later in the file, to detect whether the timers are really
enabled for VxWorks?

       AC_MSG_CHECKING([for nanosleep])
       AC_TRY_LINK(
	[#include <unistd.h>
	 #include <time.h>
	],
	[#if _POSIX_TIMERS > 0
	  timespec tp;
	 #endif
	  nanosleep(&tp, 0);
	], [ac_has_nanosleep=yes], [ac_has_nanosleep=no])

       AC_MSG_RESULT($ac_has_nanosleep)


You're the port maintainer though, so if you think that's not needed
then the patch is OK for trunk.
Olivier Hainque Dec. 22, 2019, 10:20 p.m. UTC | #2 
Hi Jonathan,

> On 19 Dec 2019, at 12:13, Jonathan Wakely <jwakely@redhat.com> wrote:
> 
> 
> Is there a way to detect that more reliably? Should we replicate the
> test used later in the file, to detect whether the timers are really
> enabled for VxWorks?
> 
>      AC_MSG_CHECKING([for nanosleep])
...
> You're the port maintainer though, so if you think that's not needed
> then the patch is OK for trunk.

Thanks for your feedback Jonathan,

Unfortunately, the AC kind of check is actually less reliable
on VxWorks, in particular for the so called "kernel" mode where
linking a "module" actually performs only a partial link to be
downloaded on a target where the run-time loader takes care of
the rest.

The current assumption on the environment configuration is on
a component included by default and required for a number
of very common time related operations anyway, so always there
in practice in our experience.

The rare/unlikely users that would not have the library
configured in on the VxWorks end would just not access to the
c++ time related facilities, which is not a problem.

Overall, this really seems like a good setting for
--enable-libstdcxx-time auto.

Olivier
Jonathan Wakely Jan. 6, 2020, 3:21 p.m. UTC | #3 
On 22/12/19 23:20 +0100, Olivier Hainque wrote:
>Hi Jonathan,
>
>> On 19 Dec 2019, at 12:13, Jonathan Wakely <jwakely@redhat.com> wrote:
>>
>>
>> Is there a way to detect that more reliably? Should we replicate the
>> test used later in the file, to detect whether the timers are really
>> enabled for VxWorks?
>>
>>      AC_MSG_CHECKING([for nanosleep])
>...
>> You're the port maintainer though, so if you think that's not needed
>> then the patch is OK for trunk.
>
>Thanks for your feedback Jonathan,
>
>Unfortunately, the AC kind of check is actually less reliable
>on VxWorks, in particular for the so called "kernel" mode where
>linking a "module" actually performs only a partial link to be
>downloaded on a target where the run-time loader takes care of
>the rest.
>
>The current assumption on the environment configuration is on
>a component included by default and required for a number
>of very common time related operations anyway, so always there
>in practice in our experience.
>
>The rare/unlikely users that would not have the library
>configured in on the VxWorks end would just not access to the
>c++ time related facilities, which is not a problem.
>
>Overall, this really seems like a good setting for
>--enable-libstdcxx-time auto.

OK, that makes sense. Thanks!
Olivier Hainque Jan. 7, 2020, 10:12 a.m. UTC | #4 
> On 6 Jan 2020, at 16:21, Jonathan Wakely <jwakely@redhat.com> wrote:
>> 
>> Overall, this really seems like a good setting for
>> --enable-libstdcxx-time auto.
> 
> OK, that makes sense. Thanks!

Sure, thank you for your feedback :)
diff mbox series

Patch

--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -1408,6 +1408,11 @@  AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [
         ac_has_nanosleep=yes
         ac_has_sched_yield=yes
         ;;
+      # VxWorks has nanosleep as soon as the kernel is configured with
+      # INCLUDE_POSIX_TIMERS, which is normally/most-often the case.
+      vxworks*)
+        ac_has_nanosleep=yes
+        ;;
       gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu)
         AC_MSG_CHECKING([for at least GNU libc 2.17])
         AC_TRY_COMPILE(
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index fa86ca1e731..717f5c1d21d 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -20871,6 +20871,11 @@  ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
         ac_has_nanosleep=yes
         ac_has_sched_yield=yes
         ;;
+      # VxWorks has nanosleep as soon as the kernel is configured with
+      # INCLUDE_POSIX_TIMERS, which is normally/most-often the case.
+      vxworks*)
+        ac_has_nanosleep=yes
+        ;;
       gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu)
         { $as_echo "$as_me:${as_lineno-$LINENO}: checking for at least GNU libc 2.17" >&5
 $as_echo_n "checking for at least GNU libc 2.17... " >&6; }