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.
