http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 14:37:39 UTC --- the difference caused by including a reference to "/usr/libgcc_s.xxx" is to allow a libgcc_s appearing in a DYLD_LIBRARY_PATH (or a fallback path in the compiler's list) to over-ride ... have you (or does the build process) set a DYLD_LIBRARY_PATH ? another possibility is a corrupted, stale or erroneous build of one of those libraries that refers to _Unwind_xxxx in FSF libgcc_s.1.dylib (how it manages that would bear some inspection). I've checked recent trunk for 10.6 and (a) libgcc_ext.dylib does NOT export _Unwind_xxxxx (b) /usr/libgcc_s.10.5.dylib is just a stub pointing to libSystem.dylib. so if you've manage to resolve _Unwind_xxxx from FSF libgcc_s then the two top choices are: either there is a dodgy -L in the build process or you've got a DYLD_LIBRARY_PATH somewhere ...