darwin may lose primary target status on FSF gcc

[Jack Howarth]

   Just a heads up for the gcc4x package maintainers here
that due to the P1 regressions in exception handling on
darwin10 for current gcc trunk (4.5), darwin may lose its
primary target status...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260#c31

I have also discovered some things about libgcc in Snow
Leopard which I was previously unaware of...

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025906.html

It appears that symbols exposed in libgcc-10.5 have now been
moved into libSystem for 10.6 and those symbols from *any* libgcc_s
aren't used (only from libSystem). What this means is that the
standard build of FSF gcc (which always links against the libgcc
it builds) is no longer really using its own libgcc. So any forking
between the unwinder in Apple's libgcc_s (now really in libSystem)
and FSF's unwinder (in it's libgcc_s) is now exposed (hence all
the exception handling regressions in gcc trunk). The solution
that I believe Apple's compiler developers are recommending is to
build FSF gcc against the systen libgcc (using --with-slib=)
and having FSF gcc upstream move all of the new symbols
(not present in libgcc-10.5) into a libgcc-ext library.
This method has already been proposed to provide the
missing emults symbols (that were added post-libgcc-10.5).

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

I'll be doing some test builds this weekend with --with-slib
on gcc trunk to see how well it survives that. It has been
ages since anyone has tried to build with the system libgcc.
                   Jack
ps I guess we shouldn't really be surprised since clang would
have an odd relationship to libgcc (so they would want to
move those symbols into libSystem).