[Bug middle-end/54806] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on x86_64-apple-darwin12

["howarth at nitro dot med.uc.edu" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806

--- Comment #19 from Jack Howarth <howarth at nitro dot med.uc.edu> 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.