[Bug libstdc++/61758] std::chrono::steady_clock::now() no longer exported

[Martin.vGagern at gmx dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758

--- Comment #4 from Martin von Gagern <Martin.vGagern at gmx dot net> ---
Thanks for the quick reply.

(In reply to Jonathan Wakely from comment #2)
> It is totally unsupported (and unlikely to work) to mix C++11 code built
> with GCC 4.x and 4.y, for any x!=y

Any particular reason why you don't change the SONAME of the library for every
change from x to y in this case?

The way I see it, this might be causing serious problems for Gentoo in the near
future. As far as I understand things, Gentoo will always dynamically link
against the latest version of libstdc++, even though different versions of gcc
(and there can be several installed concurrently) will compile against their
own matching version. Assuming ABI backwards-compatibility, at least with the
help of symbol versioning, this probably worked well enough so far. But if
there are no such guarantees for C++11 then things will break more often as
applications start to use C++11.

> Mixing code built with 4.8.x and 4.8.y should work, and does with the
> default configuration.

I've got some doubts regarding 4.8.0 to 4.8.1 since the commits I mentioned
were in between. But I don't have evidence to support my doubts, and I'm more
interested in the 4.7 to 4.8 issues.

> You didn't actually provide the information required by
> http://gcc.gnu.org/bugs such as the output of 'gcc -v' but I assume you're
> building GCC with --enable-libstdcxx-time, in which case there are fewer
> guarantees. If Gentoo is using that option

It is, as per https://bugs.gentoo.org/411681

> (which should not be necessary with GCC 4.8 anyway) then you need to
> rebuild all the libraries that depend on the <chrono> types.

Using gcc 4.8 throughout works fine, it's the mixing of a 4.7 compiler,
configured as system default, and a 4.8 library used since it's the latest,
which is causing the specific troubles on Gentoo.

> We could potentially export a steady_clock::now() compatibility symbol for
> the --enable-libstdcxx-time config, but I'd prefer to see that option go
> away rather than keep it on life support.

In what way has the ABI actually changed between chrono::steady_clock::now()
and chrono::_V2::steady_clock::now()? Looking at
http://repo.or.cz/w/official-gcc.git/blobdiff/95da0dc6f30722a5c46af68d1d6a24e7830b4b68..HEAD:/libstdc%2B%2B-v3/src/c%2B%2B11/chrono.cc
it looks to me as if you added that syscall capability, which I consider an
internal modification only, and you changed the #ifdef
_GLIBCXX_USE_CLOCK_MONOTONIC from completely removing the function to falling
back on system_clock. Right? So either the old lib did export that symbol or it
did not, but the new lib always export the symbol, and does so in a compatible
fashion. Is there any drawback from unconditionally exporting that new
implementation as an alias for the old? Something like this:

#if defined(_GLIBCXX_SYMVER_GNU) && defined(_GLIBCXX_SHARED) \
 && defined(_GLIBCXX_HAVE_AS_SYMVER_DIRECTIVE)               \
 && defined(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT)
// alias for backwards abi compatibility, see #61758
asm (".symver "
     "_ZNSt6chrono3_V212steady_clock3nowEv,"
     "_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17");
#endif

That way, you would not have to maintain the --enable-libstdcxx-time config
setting, and you would also help portability in those cases where code was
compiled on a 4.7 system with --enable-libstdcxx-time no matter the setting
used for the 4.8 system where the code is executed.