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

[Benjamin De Kosnik]

> So, there is a minor issue that what is std::chrono::steady_clock has
> changed, if you say use it as a function parameter, it will mangle
> differently before/after.  Guess not that big a deal, after all, C++11
> support is still experimental, right?

Right, ditto, yes.
 
> But the more important issue is that std::chrono::system_clock broke,
> code compiled against the old headers will assume
> std::chrono::system_clock::duration is microseconds resolution on
> Linux, while code compiled against the new headers will assume it is
> in nanoseconds resolution.  That is because of:
> #ifdef _GLIBCXX_USE_CLOCK_REALTIME
>       typedef chrono::nanoseconds
> duration; #elif defined(_GLIBCXX_USE_GETTIMEOFDAY)
>       typedef chrono::microseconds
> duration; #else
>       typedef chrono::seconds
> duration; #endif
> 
> Thus, I'm afraid we can't ABI compatibly change either of these
> macros, unless we e.g. keep old std::chrono::system_clock as is and
> introduce std::chrono::__whatever::system_clock or whatever, that
> will be typedefed as std::chrono::system_clock.

If we want to care about C++11 ABI compat on release branches
(?), here's another solution.

It scraps the renaming/aliasing approach, and just creates a
compatibility-chrono.cc that mimics the default configuration in 4.8.0.
Users who specially-configured a build with --enable-libstdcxx-time
configure options in 4.8.0 are breaking an experimental
C++ ABI anyway, so I'm not going to solve for anything but the default
case.

For chrono.cc, there is an inline namespace that mangles system_clock
and steady_clock in a new way to prevent ambiguous uses. In addition, I
make a controversial decision and just forward-declare clocks that
libstdc++ cannot do correctly, instead of using typedefs that clearly
are only going to get us into trouble as we change things down the
road. That's probably only appropriate for trunk.

Flame on, cowboys, flame on.

This still doesn't solve the solaris 9/10 librt issue.

tested x86_64/linux

-benjamin



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20130524-3.patch
Type: text/x-patch
Size: 9805 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20130525/7ce682e1/attachment.bin>