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

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

[Martin.vGagern at gmx dot net]

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

            Bug ID: 61758
           Summary: std::chrono::steady_clock::now() no longer exported
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Martin.vGagern at gmx dot net

Between 4.8.0 and 4.8.1, SVN commit 199331 changed the implementation of
compatibility-chrono.cc. Up to that point, it basically included chrono.cc
which provided implementations for system_clock and steady_clock, but bound
them to specific symbol versions. That commit changes the approach to make use
of an inline namespace, which is certainly more portable. The compatibility
implementation was modified to no longer include chrono.cc but instead
duplicate part of its functionality.

And therein lies the rub: only PART of the implementation has been copied to
the compatibility file. Now system_clock is included there, but steady_clock is
not. Which causes ABI breakage, as observed in https://bugs.gentoo.org/513386.

[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 #1 from Martin von Gagern <Martin.vGagern at gmx dot net> ---
I just read https://gcc.gnu.org/ml/gcc-patches/2013-05/msg01553.html indicating
that this is likely a deliberate ABI breakage for an experimental API. If that
is your official position, feel free to close WONTFIX. Too bad that this kind
of information contained in the email isn't included in the commit message.
Would have saved me a lot of time.

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

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
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

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

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

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.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The main problem was that --enable-libstdcxx-time used to be ABI incompatible
option in the past.

[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.

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

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Martin von Gagern from comment #4)
> (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?

Think about it. That would prevent you from combining C++03 code compiled with
different versions, and that works fine and is not experimental. Forcing
millions of lines of C++03 code to be recompiled because of changes to
experimental C++11 features would not be acceptable.

> 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.

There will be guarantees soon, when the ABI stabilises. Until then, if Gentoo
does that then it's Gentoo's problem. We can devote our limited resources to
getting the ABI stable sooner, or we can spend our time on loads of nasty hacks
to maintain compatibility for people using unsupported configurations and
expecting behaviour we never guaranteed.

> > 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.

There is no guarantee of compatibility for C++11 features between those
releases, so any issues are irrelevant.


> > (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.

You can't do that for code that uses C++11 library types. Period. Not a bug.

> 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.

I'm not interested in supporting C++11 code built with 4.7 and linking to 4.8
at runtime. Don't do that.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
As previously discussed, the --enable-libstdcxx-time function alters the
experimental C++11 ABI and is not expected to be stable.

It shouldn't be used (or necessary) going forward anyway.