search for: libgcc_ext

...mpiler. So that should be OK. It also means any new symbols introduced in main line libgcc *will* be recorded as coming from /custom/path/libgcc_s.1.dylib. Which again is what you want (as long as the functions are independent and don't need to be used in sets). And very similar to the libgcc_ext.dylib idea from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3988 -Nick On Sep 18, 2009, at 9:47 AM, Jack Howarth wrote: > Nick, > How exactly do you envision this being done? Looking at the > contents > of config/darwin.h, I see... > > /* Support -mmacosx-version-min by...

...ls symbols if I recall correctly is that those are not exposed through libgcc_s.10.5 but rather libgcc_s directly. For now, it would be better to ignore the emults issues and focus on what needs to be done to fix the unwinding. I guess you are saying we need to move the unwinders symbols out into a libgcc_ext and use that in the linkage on 10.6 or later so the FSF unwinder is used instead of the system one? Jack

Nick, How exactly do you envision this being done? Looking at the contents of config/darwin.h, I see... /* Support -mmacosx-version-min by supplying different (stub) libgcc_s.dylib libraries to link against, and by not linking against libgcc_s on earlier-than-10.3.9. Note that by default, -lgcc_eh is not linked against! This is because in a future version of Darwin the EH frame

...ll correctly is that those are not exposed > through libgcc_s.10.5 but rather libgcc_s directly. For now, it would > be better to ignore the emults issues and focus on what needs to be > done to fix the unwinding. I guess you are saying we need to move > the unwinders symbols out into a libgcc_ext and use that in the > linkage on 10.6 or later so the FSF unwinder is used instead of > the system one? > Jack The important thing is that only one unwinder is used. The _Unwind_Context data structure is different between the darwin and FSF implementations, so you ca...