http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #34 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-03 14:21:32
UTC ---
(In reply to comment #33)
> (In reply to comment #32)
>
> > So.... either
> >
> > 1/revert 163267 as proposed,
> > Are we sure that it has no effect on any other (esp. Java) test-cases?
> >
>
> I'll regression test option 1 today on darwin10. Isn't the current behavior
> (of not linking /usr/lib/libgcc_s.1.dylib) allowing any duplicate symbols
> not protected by magic symbols to gotten from FSF's libgcc_s.1.dylib
> instead of libSystem? What is the desired behavior in that case?
No, that should not (and from the testing above, does not) happen when
two-level namespace is operating (unless you override something with
DYLD_LIBRARY_PATH etc.).
the _ext stub _only_ exports the symbols we want to use from FSF libbgcc_s - so
the remainder should be (and are AFAICT) resolved from libSystem.
I think, if you check, you'll find that the 'magic symbols' are only going to
affect things when using -mmacosx-version-min=10.{4,5}.
===
Darwin 9 is unaffected, as expected, by the patch @ comment 24 +
Zforce_flat_namespace.
===
FWIW, I have also made a version of t-slibgcc-darwin that exports an _ext.dylib
(and doesn't install libgcc_s) which, as I expected, causes a bunch of
regressions on D9, so that needs to wait until we resolve the unwinder issues.
