http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107
--- Comment #25 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to David Fang from comment #22) > Do one of these apple libunwind sources (0.30, 0.35.1) correspond to what's > bundled in libgcc_s in darwin8,9,10? > > http://opensource.apple.com/tarballs/libunwind/ To be clear, For OSX 10.4 (Darwin8) and 10.5 (Darwin9) libgcc is derived from gcc sources (4.0.1) which are incompatible/buggy when combined with unwinder changes made during 4.5. The compact unwinder is not present and there is no need to consider it at all. For OSX 10.6 (Darwin 10), the libgcc functionality has been pulled into libSystem.dylib (and, I assume, is derived from BSD or other sources). IIRC, the 10.6 compact unwinder issues are to do with the library used by ld64 to build such code. FSF-gcc does not produce compact unwinder code on 10.6, and the non-compact variant works (at least insomuch as the test-suite passes). So the only places that we need to "fix" things in order to have a working unwinder are 10.4 and 10.5: What matters there is having a FAT libgcc_s.dylib that supports the corrected 'normal' unwinder. This can be achieved by building libgcc_s from recent (say 4.8) sources. The only consideration then is whether one is prepared to replace the Apple-provided version of libgcc_s with one that you've built yourself. FWIW, I'd be happy to provide FAT library builds tested on 10.5 (I run three PPC and an X86 box with 10.5). I'd also be happy to provide a version for 10.4 - although that might take longer as I have to drag old hardware out of storage to test it. Personally, I have replaced the Apple-provided libgcc_s.dylib on my Quad G5 and and 10.5 Xeon and Core2 boxen without issues - the FAT version must include PPC(7400) on X86 if one wants to use rosetta. I just build it 4-ways [i386, x86_64, ppc, ppc64] and use the same lib on x86 and ppc. However I have nowhere appropriate to host the libraries - and the responsibility for replacing the Apple-provided library absolutely needs to be in the hands of the end user. Note that 10.5 and 10.4 no longer get security updates, and it is possible to arrange symbolic links to libgcc_s versions such that the Apple version could be reinstated quickly if necessary - of course all of this requires sudo and terminal work, but Id assume that anyone building GCC from source should be able to cope with that. It really doesn't seem productive to hold 10.5 (at least) at an older unwinder - but if someone really wants to update the 4.6 patch on this thread to match the scheme now used for 4.7/4.8/trunk, I'd be happy to review.
