From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31286 invoked by alias); 19 Jan 2010 18:18:49 -0000 Received: (qmail 31275 invoked by uid 22791); 19 Jan 2010 18:18:48 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Jan 2010 18:18:44 +0000 Received: from mx10.gnu.org ([199.232.76.166]:46748) by fencepost.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NXIf4-0005No-Jd for gcc@gnu.org; Tue, 19 Jan 2010 13:18:42 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NXIf3-0003iS-HN for gcc@gnu.org; Tue, 19 Jan 2010 13:18:42 -0500 Received: from smtp-out.google.com ([216.239.44.51]:25281) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NXIf3-0003i6-9C for gcc@gnu.org; Tue, 19 Jan 2010 13:18:41 -0500 Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id o0JIIcRh004669 for ; Tue, 19 Jan 2010 10:18:38 -0800 Received: from bwz19 (bwz19.prod.google.com [10.188.26.19]) by wpaz33.hot.corp.google.com with ESMTP id o0JIIahm007201 for ; Tue, 19 Jan 2010 10:18:37 -0800 Received: by bwz19 with SMTP id 19so2649517bwz.8 for ; Tue, 19 Jan 2010 10:18:36 -0800 (PST) Received: by 10.204.154.219 with SMTP id p27mr600448bkw.115.1263925116466; Tue, 19 Jan 2010 10:18:36 -0800 (PST) Received: from coign.google.com (dhcp-172-22-124-228.mtv.corp.google.com [172.22.124.228]) by mx.google.com with ESMTPS id 14sm1353884bwz.1.2010.01.19.10.18.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 19 Jan 2010 10:18:34 -0800 (PST) To: Jon Grant Cc: gcc@gnu.org Subject: Re: Long paths with ../../../../ throughout References: <19ac3f7a1001190934q65b08a02q37f487bd735311c3@mail.gmail.com> From: Ian Lance Taylor Date: Tue, 19 Jan 2010 18:18:00 -0000 In-Reply-To: <19ac3f7a1001190934q65b08a02q37f487bd735311c3@mail.gmail.com> (Jon Grant's message of "Tue\, 19 Jan 2010 17\:34\:42 +0000") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg00377.txt.bz2 Jon Grant writes: > Any easy way to evaluate and reduce command lines? Consider this: > > /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../lib/crt1.o > > Is actually the same as: /usr/lib/crt1.o -- which is much clearer! Using this form of path makes it easy to move an installed gcc tree to a new location and have it continue to work correctly. Since normal users never see these paths, the goal is correctness rather than clarity. > Also I notice lots of duplicate parameters: > > Is this directory really needed twice? > -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3 No. I would encourage you to investigate why it is happening. > also -lgcc_s is mentioned twice, as is -gcc This is because on some systems there is a circular dependency between -lgcc and -lc. Some of the functions in -lgcc require functions in -lc. If -lc was compiled with gcc, then on some systems some of the functions in -lc will require -lgcc. Fortunately the functions which -lc requires in -lgcc will never themselves require -lc. So mentioning -lgcc twice, once before -lc and once after, suffices on all systems. > Finally, could collect2 output command lines when in -verbose mode? > Currently I can't see what parameters it is calling "ld" with.. when > ld fails. To see what collect2 is doing, use -Wl,-debug. Ian