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
