http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107
--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-21 08:24:19
UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > (In reply to comment #10)
> > > > (In reply to comment #8)
> > > So, my question is "does version 'x' work without a DYLD_LIBRARY_PATH
> > > set?"
> > > (that tells us if we have a way forward)
> > duh ... make that version 'y'.
> If you take the pure distribution gcc-4.6.0-RC-20110314 and apply the two
> patches (the patch attached in #4 and included in #5), then
> - you can bootstrap without error (i can say for C and C++ for the time
> being)
> - the xerces-c library compiles ok
> - my C++ program compiles ok
> - my C++ program executes ok with no DYLD_LIBRARY_PATH needed
Thanks Denis, that is very helpful testing - and you have, indeed, identified a
serious bug. However, I think that this set of tests indicates that the bug
is that we "emit eh_frames that are incompatible with the darwin
{8,9}-unwinder,10-compacter".
Accordingly, I suggest that either we close this bug and refer to PR41991 - or
we re-name this one to reflect its underlying cause and make it a target bug;
Mike - any preference?
> - all the dylibs and executable around carry a dependency towards
> /usr/lib/libgcc_s.1.dylib
hopefully, I have explained both that this is an intention of the current
design and why that design must be as it is.
If you can think of a viable alternative, I'd be very glad to read it.
... remembering that there are some system libraries and frameworks that are
closed source and therefore cannot be re-compiled by an end User - to say
nothing of any 3rd party commercial applications the User has installed that
were linked against a 'standard' system.
