http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107
--- Comment #30 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Denis Excoffier from comment #29) > (In reply to Iain Sandoe from comment #28) > > Well, there is a fix - which is to update > > /usr/lib/libgcc_s.dylib to a non-buggy version. > I had understood that it was desirable not to replace libgcc_s.dylib. so long as the system was maintained by the Vendor, then indeed it would be a bad thing but… see below (It's also somewhat like open-heart surgery - if you make a mistake doing the exchange then you need to boot from a different disk to recover. This makes it unsuitable, without an installer, for casual users) > Personally, i use the sed command (shown in comment #17) to create my own > libgcc_s.1.dylib, i install it with GCC in /usr/local (or equivalent) and > try to always link with it (and usually succeed since i don't use any > libraries that are already linked with /usr/lib/libgcc_s.dylib). For > security matters, that's like replacing, however. I think replacing is the proper option in this case - the security issue is moot for an unsupported EOL system. > > In any case, that bug is not NEW any more. Well, I think we should close as WONTFIX - because we don't have resources to find a better solution - and replacing the library is an acceptable work-around for EOL systems (I've now done this on both my i686 and ppc darwin9 boxes). Note: that a replacement library MUST be built FAT if you want ppc64 to work and FAT including ppc on i686-darwin9 if you want rosetta to work.
