From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22299 invoked by alias); 9 Jul 2014 12:40:38 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 22144 invoked by uid 48); 9 Jul 2014 12:40:27 -0000 From: "Martin.vGagern at gmx dot net" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: Martin.vGagern at gmx dot net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-07/txt/msg00545.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 --- Comment #4 from Martin von Gagern --- 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 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.