| Message ID | CAH6eHdTgTspzbfHhD3uDwDVD3uXAapb_NMZ0jAZ-4-UjfD4H4g@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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.
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.
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.
.. 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.
.. 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.
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.
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?
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.
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
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.
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.
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
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
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
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 }
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
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
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.
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
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.