From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19819 invoked by alias); 23 Feb 2009 22:46:21 -0000 Received: (qmail 19811 invoked by uid 22791); 23 Feb 2009 22:46:21 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from host671420017099.direcway.com (HELO aexorsyst.com) (67.142.99.170) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Feb 2009 22:46:15 +0000 Received: from hades.aexorsyst.com (hades.aexorsyst.com [192.168.1.4]) by aexorsyst.com (8.13.6/8.13.6) with ESMTP id n1NMjopO016744; Mon, 23 Feb 2009 14:45:51 -0800 From: "John Z. Bohach" To: gcc-help@gcc.gnu.org Subject: Re: collect2/ld doesn't search all paths dumped by gcc -print-search-dirs Date: Mon, 23 Feb 2009 22:46:00 -0000 User-Agent: KMail/1.9.6 Cc: Ian Lance Taylor References: <200902211728.59486.jzb2@aexorsyst.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902231445.50188.jzb2@aexorsyst.com> X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2009-02/txt/msg00171.txt.bz2 On Monday 23 February 2009 12:51:07 pm Ian Lance Taylor wrote: > "John Z. Bohach" writes: > > I'm trying to build a tiny test program using an alternate > > toolchain built purely from source (LFS ch. 5 method), but collect2 > > says that ld can't find a lib. that _does_ exist under /usr/lib, > > but /usr/lib is not even attempted as part of the search, even > > though /usr/lib _is_ part of the library search path dumped by "gcc > > -print-search-dirs". Bizarre...what am I misunderstanding? > > That certainly seems peculiar and may indicate a bug. Try running > gcc with the -v option to set the list of -L options which gcc passes > to collect2. Those options should all be passed on to the linker. > You can also run gcc with the option -Wl,-debug to see debugging > information from collect2. Thanks for the response...I think I may have figured it out... What I forgot to mention (wasn't aware of when I initially posted...) is that the original 'ld' against which gcc was compiled was been switched out. This new one has a more limited search path, and in fact appears to conform to what the real search path really is, at least as far as the linker goes. So, if the '-print-search-dirs' option results are calculated at gcc build time, and stored statically in the gcc binary, and do include the linker's search path, and it does appear to, then the peculiarity is solved. Since the linker has been switched, the static (if it is in fact static) string that is dumped by the -print-search-dirs option is stale. Probably wouldn't consider this a bug, especially because this a rare corner-case, but maybe an enhancement request to print the calculated search-dirs. based on current ld search paths, if this is in fact what I'm running into...I don't know, its probably not that important, probably only needs documentation, and this forum should count for that. Just confirmation about the string is really all that's needed, at least IMHO.