http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #5 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-01
00:32:07 UTC ---
Iain,
I think you are confused about what reverting r163267 achieves. I believe
the remaining change in r163267 was left in place because we were under the
impression that the magic symbols in darwin10 eliminated the need to place
/usr/lib/libgcc_s.dylib in front of the FSF libgcc_s.1.dylib in the linkage
order. This apparently isn't true. There must be some unprotected symbol that
Apple forget to protect. Otherwise restoring the strict behavior of having the
order...
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
625.0.0)
/Users/howarth/dist/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.1)
(which is what we do for darwin9) wouldn't eliminate the exception issues in
xplor-nih. Again note that on darwin9, we have linkages like...
libffi.dylib:
/sw/lib/gcc4.6/lib/libffi.4.dylib (compatibility version 5.0.0, current
version 5.1.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
1.0.0)
/sw/lib/gcc4.6/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
111.1.5)
so reverting the remainder of r163267 is just restoring the previous behavior
where didn't assume that the magic symbols in darwin10 would handle this for
us.
