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.