From: "Kris Warkentin" <kewarken@qnx.com>
To: "Kevin Buettner" <kevinb@redhat.com>,
"Daniel Jacobowitz" <drow@mvista.com>
Cc: "Gdb@Sources.Redhat.Com" <gdb@sources.redhat.com>
Subject: Re: Why does solib_open do what it does?
Date: Tue, 17 Jun 2003 20:15:00 -0000 [thread overview]
Message-ID: <0ab001c3350d$359af2e0$0202040a@catdog> (raw)
In-Reply-To: <1030617200144.ZM31327@localhost.localdomain>
> > That's what I was thinking too. A customer reported that when they
don't
> > set solib-search-path, all of a sudden gdb isn't finding solibs that
used to
> > be found in LD_LIBRARY_PATH.
>
> It sounds to me like the solibs in question were actually being found via
> solib-search-path, not LD_LIBRARY_PATH.
>
> I think the problem with using LD_LIBRARY_PATH is that the paths
> won't be correct without some sort of adjustment. I.e, the paths
> provided by LD_LIBRARY_PATH are target filesystem paths, not host
> paths.
Well, I've always considered searching LD_LIBRARY_PATH at all to be wrong
since the only util that should be concerned with that is the runtime
loader. Ideally, ld should be filling in the path where it found the lib
which can then be used with solib-absolute-prefix or some such.
> > You think it's okay for me to fix it?
>
> Not yet. I want to study the code some more first.
>
> Actually, the one that bothers me is (2). I think we ought to be doing
> (2) after (3).
You may be right there. I suppose we want to give the user every
opportunity to override things. I specifically put the target-defined
search function AFTER the solib-search-path lookup for just that reason. If
you're going to move 2, I would say it should be after the target defined
one so that both users and targets get a say before gdb starts looking in
places that could potentially have conflicting solibs.
cheers,
Kris
next prev parent reply other threads:[~2003-06-17 20:15 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-17 19:01 Kris Warkentin
2003-06-17 19:13 ` Daniel Jacobowitz
2003-06-17 19:14 ` Kris Warkentin
2003-06-17 19:37 ` Elena Zannoni
2003-06-17 19:47 ` Kris Warkentin
2003-06-17 20:01 ` Kevin Buettner
2003-06-17 20:15 ` Kris Warkentin [this message]
2003-06-17 20:24 ` Kevin Buettner
2003-06-18 0:14 ` Michael Snyder
2003-06-18 1:43 ` Kris Warkentin
2003-06-18 5:33 ` Kevin Buettner
2003-06-18 12:11 ` Kris Warkentin
2003-06-18 15:07 ` Kris Warkentin
2003-06-18 18:52 ` Michael Snyder
2003-06-18 19:09 ` Kris Warkentin
2003-06-18 19:20 ` Andrew Cagney
2003-06-18 20:10 ` Michael Snyder
2003-06-18 20:17 ` Kris Warkentin
2003-06-18 19:14 ` Daniel Jacobowitz
2003-06-18 18:45 ` Michael Snyder
2003-06-18 18:41 ` Michael Snyder
2003-06-18 19:16 ` Daniel Jacobowitz
2003-06-18 20:11 ` Michael Snyder
2003-06-18 20:19 ` Kris Warkentin
2003-06-18 20:27 ` Daniel Jacobowitz
2003-06-18 20:51 ` Michael Snyder
2003-06-19 12:24 ` Kris Warkentin
2003-06-19 23:33 ` Kevin Buettner
2003-06-20 0:02 ` Kevin Buettner
2003-06-20 12:28 ` Kris Warkentin
2003-06-20 12:43 ` Kevin Buettner
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='0ab001c3350d$359af2e0$0202040a@catdog' \
--to=kewarken@qnx.com \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.com \
--cc=kevinb@redhat.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