From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20176 invoked by alias); 6 Oct 2012 20:57:02 -0000 Received: (qmail 20139 invoked by uid 48); 6 Oct 2012 20:56:46 -0000 From: "howarth at nitro dot med.uc.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12 Date: Sat, 06 Oct 2012 20:57:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: howarth at nitro dot med.uc.edu X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.3 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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 X-SW-Source: 2012-10/txt/msg00564.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806 --- Comment #19 from Jack Howarth 2012-10-06 20:56:44 UTC --- (In reply to comment #18) > Note that the libgcc_ext.10.[45] are not actually needed if we're going to be > using the libgcc runtime. This is the whole reason why I suggest just removing > them entirely in a future release. The whole point of those stubs is to let > let linker pick up some of the runtime from libSystem and the rest (things > added after gcc-4.2) from the in-tree libgcc_s.dylib. If we're going to be in > the business of shipping our own compiler runtime, we don't need to let some > parts resolve to libSystem and others resolve to ours. We should just let it > all resolve to ours. My understanding is that the libgcc symbols that have been subsumed into libSystem as of darwin10 and will always override those provided by any additional libgcc. The following messages from the darwin linker developer on llvm-dev covered this and related issues with the unwinder. http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html Perhaps you are proposing that eventually we gut the duplicate symbols, now in libSystem, out of FSF libgcc_s but that would have to be done very carefully. Over a years work went into the libgcc_ext design and implementation. A similar effort would be required to gracefully replace it.