http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #58 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-05 12:21:51 UTC --- The response from Nick indicates that the documentation for -flat_namespace and two-level namespaces is correct and up to date - so we should proceed with a fix. >From a general specs point of view, I don't think we should be including libSystem in REAL_LIBGCC_SPEC, it kinda defeats the object of separating %G and %L. If we don't care about this, then let's just set one of those to "" to avoid future confusion. * We also need to watch out for the fact that fortran and java both hijack *lib to interpose their library lists. Here is a patch that should achieve the same thing as http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00274.html, but using the LINK_GCC_C_SEQUENCE_SPEC (essentially a slightly more sophisticated version of comment #17). It is probably harmless to insert libSystem before libgcc_s on Darwin 9 - since there are no unwinder symbols in Darwin 9's libSystem -- however, for the sake of consistency with other tools, I've wrapped it specifically for Darwin >= 10. (sometime I'd also like to split -no_compact_unwinder into its own macro - and provide a user way to switch it off - although it's still needed by default, as things stand). In addition to the cases already posted; for fortran, I get a link order of: -lgfortran -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem (incidentally, the presence of the unfiltered -lm in that spec means an effective additional -lSystem) and with -mmacosx-version-min=10.5: -lgfortran -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -lSystem for java -lSystem -lgcc_ext.10.5 -lgcc -lgcj /usr/lib/libiconv.dylib -lz -allow_stack_execute -lgcc_ext.10.5 -lgcc -lSystem and with -mmacosx-version-min=10.5: -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -lgcj /usr/lib/libiconv.dylib -lz -allow_stack_execute -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -lSystem ==== - I can't test the xplor package tho' so Jack might wish to do so. *** Note that, during looking at this, I discovered that libjava/libltdl has an acinclude.m4 that uses several obsolete macros, including one that inserts -flat_namespace in the sequence for undefined symbol handling - on at least Darwin 9 and 10. Needs addressing as a separate problem, of course. A temporary workaround for that is to set MACOSX_DEPLOYMENT_TARGET before building java. *** ==== IMO, we still need to fix things such that (a) we don't need to link against libgcc.a when doing shared linking (b) we change the name of our export lib (e.g. to libgcc_ext.1.dylib) and only export the symbols we need. Index: gcc/config/darwin10.h =================================================================== --- gcc/config/darwin10.h (revision 169811) +++ gcc/config/darwin10.h (working copy) @@ -1,5 +1,5 @@ /* Target definitions for Darwin (Mac OS X) systems. - Copyright (C) 2009, 2010 Free Software Foundation, Inc. + Copyright (C) 2009, 2010, 2011 Free Software Foundation, Inc. Contributed by Jack Howarth <howa...@bromo.med.uc.edu>. This file is part of GCC. @@ -18,8 +18,16 @@ You should have received a copy of the GNU General along with GCC; see the file COPYING3. If not see <http://www.gnu.org/licenses/>. */ +#undef LIB_SPEC +#define LIB_SPEC "%{!static: -lSystem }" + /* Fix PR41260 by passing -no_compact_unwind on darwin10 and later until -unwinder in libSystem is fixed to digest new epilog unwinding notes. */ + unwinder in libSystem is fixed to digest new epilog unwinding notes. */ -#undef LIB_SPEC -#define LIB_SPEC "%{!static:-no_compact_unwind -lSystem}" +/* FIXME: Work around PR47558 by linking against libSystem ahead of + libgcc_ext. */ +#undef LINK_GCC_C_SEQUENCE_SPEC +#define LINK_GCC_C_SEQUENCE_SPEC \ +"%:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind) \ + %{!static:%{!static-libgcc: \ + %:version-compare(>= 10.6 mmacosx-version-min= -lSystem) } } %G %L"