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). _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
