From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17059 invoked by alias); 20 Mar 2011 20:54:19 -0000 Received: (qmail 17049 invoked by uid 22791); 20 Mar 2011 20:54:18 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_BJ 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; Sun, 20 Mar 2011 20:54:13 +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: Sun, 20 Mar 2011 21:27: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/msg02164.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #11 from Iain Sandoe 2011-03-20 20:54:09 UTC --- (In reply to comment #10) > (In reply to comment #8) > > Now comes the question of the beginning (which is also included in the title of > this PR): why does my C++ program have (like in 'y' or 'z'+DYLD_LIBRARY_PATH) > to use a /usr/lib/libgcc_s.1.dylib (dated 2007-10-06, 264016 bytes on my Darwin > 9.8.0), when we could take advantage of the one in $(prefix)/lib (newer and > only 89656 bytes), or none at all (like in 'x')? libgcc_s (/usr/lib/libgcc_s.1.dylib) contains the unwinder for the system (which is what you need for your try/catch stuff). We are not at liberty to change that - it belongs to the distribution and is part of the suite of things Apple would update in event of security matters arising. (of course, you can overwrite Apple's lib, but then you take personal responsibility for any issues that creates - including security ones ;) ). Now the technical reason; Any system library that links with /usr/lib/libgcc_s.1.dylib - uses the unwinder from that. If you wish (and we do wish for gcc to be capable of this) to be able to make use of system libraries and frameworks - then _everyone_ MUST link the unwinder in /usr/lib/libgcc_s.1.dylib ... it's that simple. There can only be one unwinder in a single application. Now - we don't want to give up the newer capabilities of libgcc - so we made the libgcc_ext which allows you to use some newer math (and things like emulated thread local storage). > Second question, why is /usr/lib hardwired into t-slibgcc-darwin (line 31)? > That fact, let it alone, is already suspicious for me... maybe it should not be - we are living in someone else's house ;) ... we must comply with the existing infrastructure... === You can do a whole load of things that _might_ work for your particular case - - stand alone code that makes NO use of system libraries or frameworks is free to use the FSF libgcc_s ... (and you can force that with DYLD_LIBRARY_PATH). - but the configuration for gcc is intended to work in the general case (for example, people want to be able to link libobjc and pieces from CoreFoundation) ... ==== So, my question is "does version 'x' work without a DYLD_LIBRARY_PATH set?" (that tells us if we have a way forward)