This is the mail archive of the
mailing list for the libstdc++ project.
Re: [patch] Default to --enable-libstdcxx-time=auto
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, libstdc++ <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Rainer Orth <ro at cebitec dot uni-bielefeld dot de>
- Date: Wed, 22 May 2013 14:27:56 +0200
- Subject: Re: [patch] Default to --enable-libstdcxx-time=auto
- References: <CAH6eHdTgTspzbfHhD3uDwDVD3uXAapb_NMZ0jAZ-4-UjfD4H4g at mail dot gmail dot com> <519C942D dot 6050100 at oracle dot com> <CAH6eHdTjdi75WSwKYfdGBtOeQwbsSvMbzzxo24qofMexFSmETA at mail dot gmail dot com> <519C9AF5 dot 8090300 at oracle dot com> <519C9CBC dot 4050606 at oracle dot com> <519C9E3B dot 60609 at oracle dot com> <CAH6eHdRXAK1r0g7u+50RobAxTo=6DJsvRZzo75m7x+5ir3opKQ at mail dot gmail dot com> <CAH6eHdS5gqa2nfNJfC0zy9FJq4amgjJbtUuEASM_Qw0GZ8-9aA at mail dot gmail dot com> <20130522111543 dot GG1377 at tucnak dot redhat dot com> <CAH6eHdR0MocSNhvD_xRfhcYiaGugs8P++oJnTyy5DSAiDh=hPg at mail dot gmail dot com>
On 05/22/2013 01:49 PM, Jonathan Wakely wrote:
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.
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.
That kind of solution would be definitely Ok with me.