From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30805 invoked by alias); 21 Mar 2011 08:24:36 -0000 Received: (qmail 30796 invoked by uid 22791); 21 Mar 2011 08:24:35 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Mar 2011 08:24:28 +0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.6.1 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 21 Mar 2011 08:34:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg02177.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #14 from Iain Sandoe 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.