public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "Martin.vGagern at gmx dot net" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/61758] std::chrono::steady_clock::now() no longer exported Date: Wed, 09 Jul 2014 12:40:00 -0000 [thread overview] Message-ID: <bug-61758-4-uL2TQJlf12@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-61758-4@http.gcc.gnu.org/bugzilla/> 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.
next prev parent reply other threads:[~2014-07-09 12:40 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-09 9:25 [Bug libstdc++/61758] New: " Martin.vGagern at gmx dot net 2014-07-09 10:16 ` [Bug libstdc++/61758] " Martin.vGagern at gmx dot net 2014-07-09 11:40 ` redi at gcc dot gnu.org 2014-07-09 11:49 ` jakub at gcc dot gnu.org 2014-07-09 12:40 ` Martin.vGagern at gmx dot net [this message] 2014-07-09 13:01 ` redi at gcc dot gnu.org 2014-12-21 11:06 ` redi at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-61758-4-uL2TQJlf12@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).