From: "Kris Warkentin" <kewarken@qnx.com>
To: "Kevin Buettner" <kevinb@redhat.com>, <gdb@sources.redhat.com>
Subject: Re: GDB honouring RPATH in binaries.
Date: Thu, 20 Feb 2003 19:59:00 -0000 [thread overview]
Message-ID: <003d01c2d91a$974231b0$0202040a@catdog> (raw)
In-Reply-To: <1030220195520.ZM10742@localhost.localdomain>
> > > With regard to the remote case, I would have thought that simply
> > > prepending solib-absolute-prefix would give the correct results.
> >
> > Well, let's say I upload my program and libs to /tmp on the remote with
the
> > binary's RPATH set to /tmp. I'm debugging on Cygwin in
/home/kewarken/test.
> > My solib-absolute-prefix and solib-search-path are based in
> > c:\QNXsdk\target\qnx6 (where all the libs are stored). This is why I'm
not
> > convinced that there's any nice way to use RPATH in the remote case.
>
> I see what you mean. Unless you're using an NFS mount, it's unlikely
> for the sys-root on the host to contain the stuff you've just uploaded
> to /tmp.
>
> In this case, I think it would make sense to use solib-search-path
> to find the libraries that you've uploaded to /tmp.
Yes. This is really just a case of trying to automate this so that the user
has less trouble. You have no idea how many tech support calls we get which
are solved by, "make sure that gdb can find everything it needs". From what
I understand, RPATH is supposed to be THE ordained way of making sure that
the linker can find it's libs so perhaps we need to add one more case to
solib_open() where it looks through RPATH. I'm thinking that it can't hurt
and might help. Certainly it will be helpful on native debuggers.
Kris
next prev parent reply other threads:[~2003-02-20 19:59 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-20 19:15 Kris Warkentin
2003-02-20 19:33 ` Kevin Buettner
2003-02-20 19:41 ` Kris Warkentin
2003-02-20 19:55 ` Kevin Buettner
2003-02-20 19:59 ` Kris Warkentin [this message]
2003-02-20 20:03 ` Daniel Jacobowitz
2003-02-20 19:41 ` Daniel Jacobowitz
2003-02-20 19:44 ` Kris Warkentin
2003-02-20 19:48 ` Daniel Jacobowitz
2003-02-20 19:54 ` Kris Warkentin
2003-02-20 19:58 ` Kevin Buettner
2003-02-20 20:00 ` Kevin Buettner
2003-02-20 20:01 ` Kris Warkentin
2003-02-20 20:05 ` Daniel Jacobowitz
2003-02-20 20:12 ` Kris Warkentin
2003-02-20 20:04 ` Paul Koning
2003-02-20 20:10 ` Daniel Jacobowitz
2003-02-21 15:32 ` Kris Warkentin
2003-02-21 18:28 ` [Proposal] " Kris Warkentin
2003-02-21 18:30 ` Kris Warkentin
2003-02-21 18:32 ` Kris Warkentin
2003-02-21 19:14 ` Kris Warkentin
2003-02-21 19:18 ` Colin Burgess
2003-02-21 19:42 ` Kevin Buettner
2003-02-21 19:46 ` Colin Burgess
2003-02-21 19:55 ` Kris Warkentin
2003-02-21 20:27 ` Kris Warkentin
2003-02-21 21:02 ` Kevin Buettner
2003-02-21 21:04 ` Kris Warkentin
2003-02-20 20:18 ` Kevin Buettner
2003-02-20 20:00 ` Daniel Jacobowitz
2003-02-20 19:50 ` Kevin Buettner
2003-02-20 19:48 ` Kevin Buettner
2003-02-20 19:52 ` Kris Warkentin
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='003d01c2d91a$974231b0$0202040a@catdog' \
--to=kewarken@qnx.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