http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806
--- Comment #21 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-06 21:14:30 UTC --- (In reply to comment #19) > (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. yes > 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. Yes ... which is why I simply mentioned it in a comment and haven't started going down that road except as a brain exercise.
