This is the mail archive of the
mailing list for the GDB project.
[Proposal] GDB honouring RPATH in binaries.
> > Yeah, I used to see this a lot too (until we made solib-absolute-prefix
> > automatic in our tools). Unfortunately there is no clear hook to
> > figure out if a target is remote or local; and a lot of people actually
> > do use gdbserver to talk to localhost... and then there's no way to
> > know if it's the same root or not.
> Aha. Looks like our loader just fills in the basename of the lib it
> That explains why we need so much initialization of solib-search-path and
> on. I'm going to get our kernel guy to change that so that we can just
This doesn't work for us. The situation is that there might be no clear
link between the host and target directory structures. In general, all our
libs wind up in /proc/boot so when the loader fills in 'libc.so' rather than
'/proc/boot/libc.so', it's a benefit since we can use solib-search-path to
find $QNX_TARGET/$CPU/lib/libc.so, regardless of host.
So, we're stuck with initializing solib-search-path. The problem with this
is that if the user needs another path in there (as in the RPATH situation),
he has no way of appending to solib-search-path. It's either set or show.
This makes for ugly cut and paste and general unfriendlyness.
So, the proposal is either one or two. One: We could add something like
'vendor-solib-search-path' which could be searched so that solib-search-path
can be left for the user. Then vendors can just initialize v-s-s-p and
users don't have to worry. Two: provide a mechanism to append strings to
gdb variables such as solib-search-path which might be useful in other
situations. A really nice implementation would be some form of variable
set solib-search-path $solib-search-path:/home/foo