http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
--- Comment #19 from Iain Sandoe <iains at gcc dot gnu.org> ---
I have tried a number of ways to "fix" this - none of which are really
satisfactory.
1. we could keep hacking on the code gen to cater for legacy output (not a good
use of time with so many other darwin issues to deal with).
2. we could do some really hacky interposing of library code using undocumented
dyld entry points (which is quite fun, but probably not an acceptable
solution).
3. accept that the system is long out of security upgrade supports from the
vendor - and install an up-to-date libgcc_s.
4. something else (feel free to suggest).
I don't propose to investigate this further - but I am happy to provide a
pre-built FAT libgcc_s.1.dylib tested on x86-apple-darwin9 and
ppc-apple-darwin9. However, I don't have anywhere suitable to host it.
NOTE: if you build/install your own libgcc_s.1.dylib on an x86 darwin9 you
*must* build it FAT including i386/x86_64 *and* at least ppc/7400 if you want
rosetta to function.
sorry, can't justify any more effort on this one - I've replaced the
libgcc_s.1.dylib in my Darwin9 systems with one built from 4.8 tip of branch.
The gcc-4.6 solution will continue to work for anyone who wants to use it as a
local patch.
