Patchwork Default to --enable-libstdcxx-time=auto

login
register
mail settings
Submitter Jonathan Wakely
Date May 22, 2013, 8:14 a.m.
Message ID <CAH6eHdTgTspzbfHhD3uDwDVD3uXAapb_NMZ0jAZ-4-UjfD4H4g@mail.gmail.com>
Download mbox | patch
Permalink /patch/245567/
State New
Headers show

Comments

Jonathan Wakely - May 22, 2013, 8:14 a.m.
This alters the configure script to enable C++11 thread library
features based on targets that are known to support the features,
rather than based on link tests which are disabled by default.  With
Glibc 2.17 this enables a nanosecond resolution std::system_clock in
the default configuration, yay!

I've tested this on two versions of Fedora and Debian, but would be
grateful for test results on Solaris, Cygwin and BSD targets, and for
cross-compilers to any of those targets.

        * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Add KIND=auto to
        enable features if target OS is known to support them.
        * configure.ac (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Default to 'auto'.
        * configure: Regenerate.


Tested x86_64-linux, committed to trunk.
commit 47e011c33d78a00015265be39f2845209eeb97fc
Author: Jonathan Wakely <jwakely.gcc@gmail.com>
Date:   Sun Feb 3 20:45:51 2013 +0000

    	* acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Add KIND=auto to
    	enable features if target OS is known to support them.
    	* configure.ac (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Default to 'auto'.
    	* configure: Regenerate.
Paolo Carlini - May 22, 2013, 9:47 a.m.
Hi Jon,

On 05/22/2013 10:14 AM, Jonathan Wakely wrote:
> This alters the configure script to enable C++11 thread library
> features based on targets that are known to support the features,
> rather than based on link tests which are disabled by default.  With
> Glibc 2.17 this enables a nanosecond resolution std::system_clock in
> the default configuration, yay!
>
> I've tested this on two versions of Fedora and Debian, but would be
> grateful for test results on Solaris, Cygwin and BSD targets, and for
> cross-compilers to any of those targets.
>
>          * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Add KIND=auto to
>          enable features if target OS is known to support them.
>          * configure.ac (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Default to 'auto'.
>          * configure: Regenerate.
>
> Tested x86_64-linux, committed to trunk.
Thanks a lot!

Could you please double check abi_check? On this glibc 2.17 machine I'm 
seeing:

1 incompatible symbols
0
_ZNSt6chrono12steady_clock3nowEv
std::chrono::steady_clock::now()
version status: incompatible
GLIBCXX_3.4.17
type: function
status: added

I'm going to try again, just in case I goofed something.

Thanks!
Paolo.
Jonathan Wakely - May 22, 2013, 9:59 a.m.
On 22 May 2013 10:47, Paolo Carlini wrote:
>
> Could you please double check abi_check? On this glibc 2.17 machine I'm
> seeing:
>
> 1 incompatible symbols
> 0
> _ZNSt6chrono12steady_clock3nowEv
> std::chrono::steady_clock::now()
> version status: incompatible
> GLIBCXX_3.4.17
> type: function
> status: added
>
> I'm going to try again, just in case I goofed something.

No, I don't think you goofed, I see it too on glibc 2.17, sorry about that.

How should we handle that export?  It is available on older systems
without glibc 2.17 and with older GCC versions if you configure with
--enable-libstdcxx-time=rt, so it wouldn't be correct to just add it
to the GLIBCXX_3.4.19 version.
Paolo Carlini - May 22, 2013, 10:16 a.m.
Hi,

On 05/22/2013 11:59 AM, Jonathan Wakely wrote:
> On 22 May 2013 10:47, Paolo Carlini wrote:
>> Could you please double check abi_check? On this glibc 2.17 machine I'm
>> seeing:
>>
>> 1 incompatible symbols
>> 0
>> _ZNSt6chrono12steady_clock3nowEv
>> std::chrono::steady_clock::now()
>> version status: incompatible
>> GLIBCXX_3.4.17
>> type: function
>> status: added
>>
>> I'm going to try again, just in case I goofed something.
> No, I don't think you goofed, I see it too on glibc 2.17, sorry about that.
>
> How should we handle that export?  It is available on older systems
> without glibc 2.17 and with older GCC versions if you configure with
> --enable-libstdcxx-time=rt,
I don't think it could be available on older systems without something 
like --enable-libstdcxx-time=rt on the command line. That is, without a 
non-default configure switch. Anyway, indeed it could be available, 
depending on the configuration and we wanted it to be exported, in case. 
I think there isn't a risk of real, substantive abi-breakage here, the 
issue is largely about the way we are testing abi_check. I bet Jakub has 
ideas about the best way to approach this, like with the alias 
mechanism?!? Essentially we want to arrange things in such a way that 
this specific symbol is fine to be optionally exported at *any* version 
 >= GLIBCXX_3.4.17 (thus, no abi_check error), depending on the 
configure switch.

Paolo.
Paolo Carlini - May 22, 2013, 10:23 a.m.
.. an idea I have got: we could arrange for defining the symbol 
unconditionally, even when isn't really meaningful in that clock 
configuration, and therefore exporting it uncondtionally, a dummy 
implementation in many configuration. We also have at the same time to 
regenerate the baselines to include it, not a big deal. Maybe Rainer can 
also help... he pays a lot of attention to this kind of issue.

Paolo.
Paolo Carlini - May 22, 2013, 10:30 a.m.
.. put an abort or something in the dummy implementations, to make sure 
people don't try to run an executable built with headers which have the 
clock available linked at run time to a .so which doesn't, really. 
Suboptimal solution because ideally we would like to fail at build time, 
but this is the best I have got so far. Be very clear in the docs, anyway.

Paolo.
Jonathan Wakely - May 22, 2013, 10:40 a.m.
On 22 May 2013 11:30, Paolo Carlini wrote:
> .. put an abort or something in the dummy implementations, to make sure
> people don't try to run an executable built with headers which have the
> clock available linked at run time to a .so which doesn't, really.
> Suboptimal solution because ideally we would like to fail at build time, but
> this is the best I have got so far. Be very clear in the docs, anyway.

Based on feedback for <regex> users much prefer to have something
undefined than to have it defined but non-functional or causing an
abort.
Jonathan Wakely - May 22, 2013, 10:42 a.m.
On 22 May 2013 11:40, Jonathan Wakely wrote:
> On 22 May 2013 11:30, Paolo Carlini wrote:
>> .. put an abort or something in the dummy implementations, to make sure
>> people don't try to run an executable built with headers which have the
>> clock available linked at run time to a .so which doesn't, really.
>> Suboptimal solution because ideally we would like to fail at build time, but
>> this is the best I have got so far. Be very clear in the docs, anyway.
>
> Based on feedback for <regex> users much prefer to have something
> undefined than to have it defined but non-functional or causing an
> abort.

Could leave the steady_clock::now() symbol "undesignated", like the
__once_call and __once_callable symbols that are only present when
_GLIBCXX_HAVE_TLS is defined?
Paolo Carlini - May 22, 2013, 10:48 a.m.
On 05/22/2013 12:40 PM, Jonathan Wakely wrote:
> On 22 May 2013 11:30, Paolo Carlini wrote:
>> .. put an abort or something in the dummy implementations, to make sure
>> people don't try to run an executable built with headers which have the
>> clock available linked at run time to a .so which doesn't, really.
>> Suboptimal solution because ideally we would like to fail at build time, but
>> this is the best I have got so far. Be very clear in the docs, anyway.
> Based on feedback for <regex> users much prefer to have something
> undefined than to have it defined but non-functional or causing an
> abort.
That for sure. But I don't think the situation is exactly the same, to 
be honest. Note, I don't know what exactly "undesignated" means, I 
understand you already used that approach, thus don't hesitate to try it 
here too!

Take your time (no pun intended ;) you may want to disable temporarily 
the auto with a FIXME comment.

Paolo.
Jakub Jelinek - May 22, 2013, 11:15 a.m.
On Wed, May 22, 2013 at 11:42:45AM +0100, Jonathan Wakely wrote:
> On 22 May 2013 11:40, Jonathan Wakely wrote:
> > On 22 May 2013 11:30, Paolo Carlini wrote:
> >> .. put an abort or something in the dummy implementations, to make sure
> >> people don't try to run an executable built with headers which have the
> >> clock available linked at run time to a .so which doesn't, really.
> >> Suboptimal solution because ideally we would like to fail at build time, but
> >> this is the best I have got so far. Be very clear in the docs, anyway.
> >
> > Based on feedback for <regex> users much prefer to have something
> > undefined than to have it defined but non-functional or causing an
> > abort.
> 
> Could leave the steady_clock::now() symbol "undesignated", like the
> __once_call and __once_callable symbols that are only present when
> _GLIBCXX_HAVE_TLS is defined?

For now() I think it was a mistake not to export it (generally, exports
conditional on supposedly non-ABI changing configure options are bad IMHO),
can't it just return some perhaps less precise clock or something instead?

The problem with having libstdc++.so's without now()@@GLIBCXX_3.4.17
exported in the wild and now new default flag builds having those
is quite a big ABI problem, say rpm dependency tracking will not spot those,
it only looks at symbol version names, not at individual symbols, so
programs that will try to call that symbol might fail only at runtime.

If now() can be perhaps with worse precision emulated in configurations not
built against glibc 2.17, perhaps best solution would be to
add now()@@GLIBCXX_3.4.18 into 4.8.1 (and change all 3.4.18 symbols to
3.4.19) and have now()@GLIBCXX_3.4.17 (note, just one @) as compatibility
alias to that.

	Jakub
Jonathan Wakely - May 22, 2013, 11:49 a.m.
On 22 May 2013 12:15, Jakub Jelinek wrote:
>
> If now() can be perhaps with worse precision emulated in configurations not
> built against glibc 2.17, perhaps best solution would be to
> add now()@@GLIBCXX_3.4.18 into 4.8.1 (and change all 3.4.18 symbols to
> 3.4.19) and have now()@GLIBCXX_3.4.17 (note, just one @) as compatibility
> alias to that.

The problem for steady_clock::now() isn't one of precision, it's that
it isn't steady if we don't use the monotonic clock.  We could define
a non-steady steady_clock (with the same precision as system_clock)
but is that helpful to users?  If that's what we want then yes, we can
do the symbol versioning you suggest.
Paolo Carlini - May 22, 2013, 12:27 p.m.
On 05/22/2013 01:49 PM, Jonathan Wakely wrote:
> On 22 May 2013 12:15, Jakub Jelinek wrote:
>> If now() can be perhaps with worse precision emulated in configurations not
>> built against glibc 2.17, perhaps best solution would be to
>> add now()@@GLIBCXX_3.4.18 into 4.8.1 (and change all 3.4.18 symbols to
>> 3.4.19) and have now()@GLIBCXX_3.4.17 (note, just one @) as compatibility
>> alias to that.
> The problem for steady_clock::now() isn't one of precision, it's that
> it isn't steady if we don't use the monotonic clock.  We could define
> a non-steady steady_clock (with the same precision as system_clock)
> but is that helpful to users?  If that's what we want then yes, we can
> do the symbol versioning you suggest.
If I understand correctly Jakub's idea, nothing would change from the 
user point of view in the headers, using now would be still a no-no if 
the real facility isn't implemented. It would be only a run-time fall 
back for the situation I mentioned before: the binary is built with 
headers providing a good clock and then moved to another machine, and 
dynamically linked to a library which doesn't and then run. We could 
also spill a warning, at run-time.

That kind of solution would be definitely Ok with me.

Paolo.
Jonathan Wakely - May 22, 2013, 12:31 p.m.
On 22 May 2013 12:49, Jonathan Wakely wrote:
> On 22 May 2013 12:15, Jakub Jelinek wrote:
>>
>> If now() can be perhaps with worse precision emulated in configurations not
>> built against glibc 2.17, perhaps best solution would be to
>> add now()@@GLIBCXX_3.4.18 into 4.8.1 (and change all 3.4.18 symbols to
>> 3.4.19) and have now()@GLIBCXX_3.4.17 (note, just one @) as compatibility
>> alias to that.
>
> The problem for steady_clock::now() isn't one of precision, it's that
> it isn't steady if we don't use the monotonic clock.  We could define
> a non-steady steady_clock (with the same precision as system_clock)
> but is that helpful to users?  If that's what we want then yes, we can
> do the symbol versioning you suggest.

In fact we were already providing a non-steady steady_clock in the
default configuration, we just define it as a typedef for
system_clock, so we can export steady_clock::now() as an alias for
system_clock::now() when the two clocks are the same type.  When
they're not the same type there will be a real symbol present in the
.so
Jakub Jelinek - May 22, 2013, 12:35 p.m.
On Wed, May 22, 2013 at 12:49:44PM +0100, Jonathan Wakely wrote:
> On 22 May 2013 12:15, Jakub Jelinek wrote:
> >
> > If now() can be perhaps with worse precision emulated in configurations not
> > built against glibc 2.17, perhaps best solution would be to
> > add now()@@GLIBCXX_3.4.18 into 4.8.1 (and change all 3.4.18 symbols to
> > 3.4.19) and have now()@GLIBCXX_3.4.17 (note, just one @) as compatibility
> > alias to that.
> 
> The problem for steady_clock::now() isn't one of precision, it's that
> it isn't steady if we don't use the monotonic clock.  We could define
> a non-steady steady_clock (with the same precision as system_clock)
> but is that helpful to users?  If that's what we want then yes, we can
> do the symbol versioning you suggest.

There are two things.  One is offering to use steady_clock::now() at
compile time, even if we know the clock isn't steady (here sure, I think
preferrably don't offer that), but the second thing is, if you have
already linked program which uses steady clock, what is better, not be
able to dynamically link it at all (steady_clock use might be in some
library and you don't ever call now() in your program), or to
abort/std::terminate when now() is called in your program, or you offer
non-steady clock instead.  Or, have you also considered just using
for this routine
#if _GLIBCXX_HAS_SYS_SYSCALL_H
#include <sys/syscall.h>
#endif

#if defined (SYS_clock_gettime) && defined (CLOCK_MONOTONIC)
syscall (SYS_clock_gettime, CLOCK_MONOTONIC, &tp);
#endif
if clock_gettime isn't available, at least on Linux?
The implementation seems to ignore ENOSYS from clock_gettime, so ignoring it
even here wouldn't make it worse.

	Jakub
Steve Ellcey - May 28, 2013, 4:10 p.m.
On Wed, 2013-05-22 at 09:14 +0100, Jonathan Wakely wrote:
> This alters the configure script to enable C++11 thread library
> features based on targets that are known to support the features,
> rather than based on link tests which are disabled by default.  With
> Glibc 2.17 this enables a nanosecond resolution std::system_clock in
> the default configuration, yay!
> 
> I've tested this on two versions of Fedora and Debian, but would be
> grateful for test results on Solaris, Cygwin and BSD targets, and for
> cross-compilers to any of those targets.
> 
>         * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Add KIND=auto to
>         enable features if target OS is known to support them.
>         * configure.ac (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Default to 'auto'.
>         * configure: Regenerate.
> 
> 
> Tested x86_64-linux, committed to trunk.

Jonathan,

This has broken the mips-mti-elf build for me, this target uses newlib
and I am building with the latest newlib sources as well as the latest
GCC sources.  I don't know if this is related to the problem that others
have had or not.  I saw emails about test failures but not about build
failures.  The problem I get when building a x86 to mips cross compiler
is:

/local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc: In static member function 'static std::chrono::system_clock::time_point std::chrono::system_clock::now()':
/local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc:81:14: error: 'from_time_t' is not a member of 'std::chrono::system_clock'
       return system_clock::from_time_t(__sec);
              ^
/local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc:83:5: warning: control reaches end of non-void function [-Wreturn-type]
     }

I will dig around some more but I thought I would see if you had any
ideas on what the problem was and how to fix it.

Steve Ellcey
sellcey@imgtec.com
Jonathan Wakely - May 28, 2013, 4:29 p.m.
On 28 May 2013 17:10, Steve Ellcey wrote:
> On Wed, 2013-05-22 at 09:14 +0100, Jonathan Wakely wrote:
>> This alters the configure script to enable C++11 thread library
>> features based on targets that are known to support the features,
>> rather than based on link tests which are disabled by default.  With
>> Glibc 2.17 this enables a nanosecond resolution std::system_clock in
>> the default configuration, yay!
>>
>> I've tested this on two versions of Fedora and Debian, but would be
>> grateful for test results on Solaris, Cygwin and BSD targets, and for
>> cross-compilers to any of those targets.
>>
>>         * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Add KIND=auto to
>>         enable features if target OS is known to support them.
>>         * configure.ac (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Default to 'auto'.
>>         * configure: Regenerate.
>>
>>
>> Tested x86_64-linux, committed to trunk.
>
> Jonathan,
>
> This has broken the mips-mti-elf build for me,

I don't think it was my patch that broke it, because
compatibility-chrono.cc didn't exist when my patch went in  :-)


> this target uses newlib
> and I am building with the latest newlib sources as well as the latest
> GCC sources.  I don't know if this is related to the problem that others
> have had or not.  I saw emails about test failures but not about build
> failures.  The problem I get when building a x86 to mips cross compiler
> is:
>
> /local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc: In static member function 'static std::chrono::system_clock::time_point std::chrono::system_clock::now()':
> /local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc:81:14: error: 'from_time_t' is not a member of 'std::chrono::system_clock'
>        return system_clock::from_time_t(__sec);
>               ^
> /local/home/sellcey/nightly2/src/gcc/libstdc++-v3/src/c++11/compatibility-chrono.cc:83:5: warning: control reaches end of non-void function [-Wreturn-type]
>      }
>
> I will dig around some more but I thought I would see if you had any
> ideas on what the problem was and how to fix it.

Does this help?

--- src/c++11/compatibility-chrono.cc.orig      2013-05-28
17:27:54.631919423 +0100
+++ src/c++11/compatibility-chrono.cc   2013-05-28 17:28:43.697861786 +0100
@@ -78,7 +78,9 @@
                                 + chrono::microseconds(tv.tv_usec)));
 #else
       std::time_t __sec = std::time(0);
-      return system_clock::from_time_t(__sec);
+      typedef chrono::time_point<system_clock, seconds>        __from;
+      return time_point_cast<system_clock::duration>
+              (__from(chrono::seconds(__sec)));
 #endif
     }
Jakub Jelinek - May 28, 2013, 4:32 p.m.
On Tue, May 28, 2013 at 05:29:38PM +0100, Jonathan Wakely wrote:
> > This has broken the mips-mti-elf build for me,
> 
> I don't think it was my patch that broke it, because
> compatibility-chrono.cc didn't exist when my patch went in  :-)

Yeah, this is from the latest change set.  

> Does this help?

I'd say it should (my version just added from_time_t to
compatibility-chrono.cc, but your version is probably better); so, if
this fixes it for the reporter, please commit it also to 4.8 branch.

Thanks.

> --- src/c++11/compatibility-chrono.cc.orig      2013-05-28
> 17:27:54.631919423 +0100
> +++ src/c++11/compatibility-chrono.cc   2013-05-28 17:28:43.697861786 +0100
> @@ -78,7 +78,9 @@
>                                  + chrono::microseconds(tv.tv_usec)));
>  #else
>        std::time_t __sec = std::time(0);
> -      return system_clock::from_time_t(__sec);
> +      typedef chrono::time_point<system_clock, seconds>        __from;
> +      return time_point_cast<system_clock::duration>
> +              (__from(chrono::seconds(__sec)));
>  #endif
>      }

	Jakub
Steve Ellcey - May 28, 2013, 5:39 p.m.
On Tue, 2013-05-28 at 17:29 +0100, Jonathan Wakely wrote:

> 
> I don't think it was my patch that broke it, because
> compatibility-chrono.cc didn't exist when my patch went in  :-)

Sorry about that, I guess I got lost in a maze of twisty checkins.

> Does this help?
> 
> --- src/c++11/compatibility-chrono.cc.orig      2013-05-28
> 17:27:54.631919423 +0100
> +++ src/c++11/compatibility-chrono.cc   2013-05-28 17:28:43.697861786 +0100
> @@ -78,7 +78,9 @@
>                                  + chrono::microseconds(tv.tv_usec)));
>  #else
>        std::time_t __sec = std::time(0);
> -      return system_clock::from_time_t(__sec);
> +      typedef chrono::time_point<system_clock, seconds>        __from;
> +      return time_point_cast<system_clock::duration>
> +              (__from(chrono::seconds(__sec)));
>  #endif
>      }

Yes, it does.  My build worked fine after applying this patch to my
local tree.

Steve Ellcey
sellcey@imgtec.com
Jonathan Wakely - May 28, 2013, 5:46 p.m.
On 28 May 2013 18:39, Steve Ellcey wrote:
> On Tue, 2013-05-28 at 17:29 +0100, Jonathan Wakely wrote:
>
>>
>> I don't think it was my patch that broke it, because
>> compatibility-chrono.cc didn't exist when my patch went in  :-)
>
> Sorry about that, I guess I got lost in a maze of twisty checkins.

Well the later checkins were Jakub and Benjamin fixing the unexpected
fallout from my one, so it was all related.

>> Does this help?
>>
>> --- src/c++11/compatibility-chrono.cc.orig      2013-05-28
>> 17:27:54.631919423 +0100
>> +++ src/c++11/compatibility-chrono.cc   2013-05-28 17:28:43.697861786 +0100
>> @@ -78,7 +78,9 @@
>>                                  + chrono::microseconds(tv.tv_usec)));
>>  #else
>>        std::time_t __sec = std::time(0);
>> -      return system_clock::from_time_t(__sec);
>> +      typedef chrono::time_point<system_clock, seconds>        __from;
>> +      return time_point_cast<system_clock::duration>
>> +              (__from(chrono::seconds(__sec)));
>>  #endif
>>      }
>
> Yes, it does.  My build worked fine after applying this patch to my
> local tree.

Excellent, thanks. I'll commit that in an hour or two when I get home.

Patch

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 619fff0..efeb6d4 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -871,7 +871,8 @@  dnl    (FEATURE, DEFAULT, HELP-ARG, HELP-STRING)
 dnl    (FEATURE, DEFAULT, HELP-ARG, HELP-STRING, permit a|b|c)
 dnl    (FEATURE, DEFAULT, HELP-ARG, HELP-STRING, SHELL-CODE-HANDLER)
 dnl
-dnl See docs/html/17_intro/configury.html#enable for documentation.
+dnl See manual/appendix_porting.html#appendix.porting.build_hacking for
+dnl documentation.
 dnl
 m4_define([GLIBCXX_ENABLE],[dnl
 m4_define([_g_switch],[--enable-$1])dnl
@@ -1161,8 +1162,9 @@  dnl        nanosleep and sched_yield in libc and libposix4 and, if needed,
 dnl        links in the latter.
 dnl --enable-libstdcxx-time=rt
 dnl        also searches (and, if needed, links) librt.  Note that this is
-dnl        not always desirable because, in glibc, for example, in turn it
-dnl        triggers the linking of libpthread too, which activates locking,
+dnl        not always desirable because, in glibc 2.16 and earlier, for
+dnl        example, in turn it triggers the linking of libpthread too,
+dnl        which activates locking,
 dnl        a large overhead for single-thread programs.
 dnl --enable-libstdcxx-time=no
 dnl --disable-libstdcxx-time
@@ -1175,8 +1177,7 @@  dnl os_defines.h and also defines _GLIBCXX_USE_SCHED_YIELD.
 dnl
 AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [
 
-  AC_MSG_CHECKING([for clock_gettime, nanosleep and sched_yield])
-  GLIBCXX_ENABLE(libstdcxx-time,$1,[[[=KIND]]],
+  GLIBCXX_ENABLE(libstdcxx-time,auto,[[[=KIND]]],
     [use KIND for check type],
     [permit yes|no|rt])
 
@@ -1188,9 +1189,59 @@  AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [
 
   ac_has_clock_monotonic=no
   ac_has_clock_realtime=no
-  AC_MSG_RESULT($enable_libstdcxx_time)
+  ac_has_nanosleep=no
+  ac_has_sched_yield=no
+
+  if test x"$enable_libstdcxx_time" = x"auto"; then
+
+    case "${target_os}" in
+      cygwin*)
+        ac_has_nanosleep=yes
+        ;;
+      darwin*)
+        ac_has_nanosleep=yes
+        ac_has_sched_yield=yes
+        ;;
+      gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu)
+        AC_MSG_CHECKING([for at least GNU libc 2.17])
+        AC_TRY_COMPILE(
+          [#include <features.h>],
+          [
+          #if ! __GLIBC_PREREQ(2, 17)
+          #error 
+          #endif
+          ],
+          [glibcxx_glibc217=yes], [glibcxx_glibc217=no])
+        AC_MSG_RESULT($glibcxx_glibc217)
+
+        if test x"$glibcxx_glibc217" = x"yes"; then
+          ac_has_clock_monotonic=yes
+          ac_has_clock_realtime=yes
+        fi
+        ac_has_nanosleep=yes
+        ac_has_sched_yield=yes
+        ;;
+      freebsd*|netbsd*)
+        ac_has_clock_monotonic=yes
+        ac_has_clock_realtime=yes
+        ac_has_nanosleep=yes
+        ac_has_sched_yield=yes
+        ;;
+      openbsd*)
+        ac_has_clock_monotonic=yes
+        ac_has_clock_realtime=yes
+        ac_has_nanosleep=yes
+        ;;
+      solaris*)
+        GLIBCXX_LIBS="$GLIBCXX_LIBS -lrt"
+        ac_has_clock_monotonic=yes
+        ac_has_clock_realtime=yes
+        ac_has_nanosleep=yes
+        ac_has_sched_yield=yes
+        ;;
+    esac
 
-  if test x"$enable_libstdcxx_time" != x"no"; then
+  elif test x"$enable_libstdcxx_time" != x"no"; then
 
     if test x"$enable_libstdcxx_time" = x"rt"; then
       AC_SEARCH_LIBS(clock_gettime, [rt posix4])
@@ -1214,19 +1265,16 @@  AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [
     case "$ac_cv_search_sched_yield" in
       -lposix4*)
       GLIBCXX_LIBS="$GLIBCXX_LIBS $ac_cv_search_sched_yield"
-      AC_DEFINE(_GLIBCXX_USE_SCHED_YIELD, 1,
-		[ Defined if sched_yield is available. ])
+      ac_has_sched_yield=yes
       ;;
       -lrt*)
       if test x"$enable_libstdcxx_time" = x"rt"; then
 	GLIBCXX_LIBS="$GLIBCXX_LIBS $ac_cv_search_sched_yield"
-	AC_DEFINE(_GLIBCXX_USE_SCHED_YIELD, 1,
-		  [ Defined if sched_yield is available. ])
+        ac_has_sched_yield=yes
       fi
       ;;
       *)
-      AC_DEFINE(_GLIBCXX_USE_SCHED_YIELD, 1,
-		[ Defined if sched_yield is available. ])
+      ac_has_sched_yield=yes
       ;;
     esac
 
@@ -1284,6 +1332,11 @@  AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [
       [ Defined if clock_gettime has realtime clock support. ])
   fi
 
+  if test x"$ac_has_sched_yield" = x"yes"; then
+    AC_DEFINE(_GLIBCXX_USE_SCHED_YIELD, 1,
+              [ Defined if sched_yield is available. ])
+  fi
+
   if test x"$ac_has_nanosleep" = x"yes"; then
     AC_DEFINE(_GLIBCXX_USE_NANOSLEEP, 1,
       [ Defined if nanosleep is available. ])
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index 73d430a..f6ba176 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -198,8 +198,7 @@  GLIBCXX_COMPUTE_STDIO_INTEGER_CONSTANTS
 GLIBCXX_CHECK_GETTIMEOFDAY
 
 # For clock_gettime, nanosleep and sched_yield support.
-# NB: The default is [no], because otherwise it requires linking.
-GLIBCXX_ENABLE_LIBSTDCXX_TIME([no])
+GLIBCXX_ENABLE_LIBSTDCXX_TIME
 
 AC_LC_MESSAGES