From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28708 invoked by alias); 8 Feb 2005 07:22:37 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 28696 invoked by uid 48); 8 Feb 2005 07:22:33 -0000 Date: Tue, 08 Feb 2005 15:14:00 -0000 Message-ID: <20050208072233.28695.qmail@sourceware.org> From: "ryan dot oliver at pha dot com dot au" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050110021617.19353.gschafer@zip.com.au> References: <20050110021617.19353.gschafer@zip.com.au> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug driver/19353] Faulty handling of startfile_prefix_spec X-Bugzilla-Reason: CC X-SW-Source: 2005-02/txt/msg00499.txt.bz2 List-Id: ------- Additional Comments From ryan dot oliver at pha dot com dot au 2005-02-08 07:22 ------- (In reply to comment #5) > The patch was approved by the RM here: > > http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00850.html > > but it is still not applied. It would be great if you could pls commit this > patch then close the BZ. > > Many thanks. Greetings, coming in a bit late here... I have noticed that startfile_prefix_spec is still handled by the driver as of 20050208. I would personally not like to see this feature go, as it is incredibly useful when building multilib toolchains (be it native or cross) where the startfiles and libraries are not located in standard locations, and not located under the prefix the compiler was installed to. Fair enough nothing internal to the gcc build still uses it, but it still has a use... Main thing it facilitates is building a multilib gcc linked against c-libraries in a non standard location (te create a self hosted toolchain) Use of -B/target/lib to specify the location of startfiles will not fly, you end up linking in 32bit startfiles into your 64bit libgcc. Unless there is another mechanism for specifying the location, and have it get adjusted by the multilib spec, multilib gcc builds in this scenario aren't possible (without much hackery and pain). Here the simple adjustment of startfile_prefix_spec to /target/lib/ ensures everything will build correctly. It also proves invaluable when cross-compiling a self-hosted toolchain for a multilib target w/o using --with-sysroot (which isn't appropriate in all circumstances) I do hope that you will reconsider the full application of this patch, true it wont take a lot to maintain a patch which reverts these changes, but I surely would prefer to not have to do so... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353