http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #35 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-03 14:29:25
UTC ---
(In reply to comment #34)
> (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
I don't think the magic symbols are what causes the change.
when /usr/lib/libgcc_s.10.5.dylib is linked before the ext - it causes
/usr/lib/libgcc_s.1.dylib to be placed as an reference in the object.
On a live system (with no DYLD_LIBRARY_PATHS) that is fine - because
/usr/lib/libgcc_s.1.dylib is just a symlink to libSystem.dylib
However, when you run the test-suite DYLD_LIBRARY_PATH -> ${build}/gcc which
contains the FSF libgcc_s.1.dylib and that will satisfy the linkage when
libgcc_s.1.dylib appears in the exe.
Obviously, with the current trunk - we don't reference
/usr/lib/libgcc_s.1.dylib on D10 and, therefore, the lib in ${build}/gcc is
irrelevant (to D10 ... unfortunately, that's not the case for D<10).
Let's see how your testing goes.
