From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20005 invoked by alias); 27 Jun 2013 23:20:20 -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 19943 invoked by uid 55); 27 Jun 2013 23:20:16 -0000 From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/57740] C++11 std::thread not usable with static linking Date: Thu, 27 Jun 2013 23:20: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: joseph at codesourcery dot com 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: 2013-06/txt/msg01733.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740 --- Comment #10 from joseph at codesourcery dot com --- On Thu, 27 Jun 2013, pinskia at gcc dot gnu.org wrote: > No it does not. Or rather there have not been an ABI change in libstdc++ since > 3.4. If you compile with the oldest distro you support, it should work across > all distros just fine. Just C++11 support was not part of most older distros > because they came out before 2011 :). Compiling with a (newer) cross compiler built with a sysroot from the old distro has various advantages over actually trying to build directly on the old distro - but you do then need to use -static-libstdc++ -static-libgcc to avoid depending on newer shared libraries. (Actually, a sysroot just containing the old glibc libraries, with all other libraries linked in statically, seems to work better in my experience than a complete old-distro sysroot with old versions of lots of libraries; there are lots of ways an old library can cause problems for building new software where complete absence of that library is detected at configure time and doesn't cause problems.) In theory this (building widely portable binaries) is what LSB toolchains are for, but I don't think they are widely used.