Re: [patch] Default to --enable-libstdcxx-time=auto

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, May 23, 2013 at 11:54:05PM +0200, Rainer Orth wrote:
> > Agreed, that seems the best course of action if that's an option.
> 
> I just remembered that we aren't there yet even on mainline:
> 
> * This snippet
> 
>   http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01255.html
> 
>   is necessary to avoid bootstrap failure on Solaris 9.
> 
> * We'll need to link every C++ program with -lrt on Solaris, as
>   mentioned in the same message.  I suppose the best way to do this is
>   along the lines of libgfortran.spec, rather than duplicate the
>   necessary configury between g++ and libstdc++.  This might prove
>   pretty invasive for the testsuite, though, and delay the 4.8.1 release
>   quite a bit.

Ugh, that makes =auto pretty much unbackportable, but it seems Solaris is
the only problematic OS here.  The goal of
_ZNSt6chrono12steady_clock3nowEv@@GLIBCXX_3.4.19
already in 4.8.1 was to allow Linux users (and with partial backport of
=auto not including Solaris perhaps also FreeBSD/NetBSD/OpenBSD) to let
users that get C++ core language feature completeness also use this
(Jonathan/Benjamin, is that right?).

So, let's talk about other options, is constexpr/const on
std::chrono::steady_clock::is_steady
required by the standard (as in, could we export
_ZNSt6chrono12steady_clock9is_steadyE@@GLIBCXX_3.4.19
and let the library say which case it is, it would be constexpr when
we know for sure, and a static variable otherwise)?
But looking at C++11 draft, in [time.clock.steady]
it even says that is_steady is true (then we are violating the standard
even when we represent steady_clock as typedef system_clock steady_clock;).

Thus, what about this version (just slightly modified, headers remain the
same, but we export _ZNSt6chrono12steady_clock3nowEv@@GLIBCXX_3.4.19
even if monotonic clock isn't supported, it will just be work the same as
_ZNSt6chrono12system_clock3nowEv@@GLIBCXX_3.4.11 .  Programs compiled
against headers of the same libstdc++ as will be linked in dynamically
won't see a change, because they will never use this symbol of monotonic
clocks weren't determined to be there at configure time.  And we have a
fallback for the unlikely matching of newer headers with older libstdc++,
it will work roughly as before (in that steady_clock::now () will not be
steady), just with the tiny exception that in that case the code could
see that steady_clock::is_steady is true rather than false (but, can't
the code assume it from the standard anyway)?

I've also added the #ifdef HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT
guards in gnu.ver.

	Jakub

Attachment: 49
Description: Text document

Attachment: 48
Description: Text document