This is the mail archive of the
mailing list for the GDB project.
Re: [Proposal] GDB honouring RPATH in binaries.
On Feb 21, 1:30pm, Kris Warkentin wrote:
> > 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
> > solib-absolute-prefix.
> 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 on the target image 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.
I still find myself confused as to why your loader only wants to fill
in the basename. Having an absolute path won't preclude using
solib-search-path. And it will certainly make things easier when you
have an accurate target image residing (somewhere) on the host so that you
can use solib-absolute-prefix.
> 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, I have two potential solutions:
> 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.
I'm not in favor of this.
> 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 expansion, ie:
> set solib-search-path $solib-search-path:/home/foo
I think something like this has been discussed before. It sounds like
a good idea to me.