public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "John Z. Bohach" <jzb2@aexorsyst.com>
To: gcc-help@gcc.gnu.org
Cc: Ian Lance Taylor <iant@google.com>
Subject: Re: collect2/ld doesn't search all paths dumped by gcc -print-search-dirs
Date: Mon, 23 Feb 2009 22:46:00 -0000	[thread overview]
Message-ID: <200902231445.50188.jzb2@aexorsyst.com> (raw)
In-Reply-To: <m3eixoj2ro.fsf@google.com>

On Monday 23 February 2009 12:51:07 pm Ian Lance Taylor wrote:
> "John Z. Bohach" <jzb2@aexorsyst.com> 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.




      reply	other threads:[~2009-02-23 22:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-22  1:29 John Z. Bohach
2009-02-23 20:51 ` Ian Lance Taylor
2009-02-23 22:46   ` John Z. Bohach [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200902231445.50188.jzb2@aexorsyst.com \
    --to=jzb2@aexorsyst.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=iant@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).