Re: [Proposal] GDB honouring RPATH in binaries.

[Kevin Buettner <kevinb at redhat dot com>]

On Feb 21,  1:30pm, Kris Warkentin wrote:

> > Aha.  Looks like our loader just fills in the basename of the lib it
> finds.
> > That explains why we need so much initialization of solib-search-path and
> so
> > on.  I'm going to get our kernel guy to change that so that we can just
> use
> > 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.

Kevin