Why does solib_open do what it does?

[Kris Warkentin]

> >>I rather think that $PATH and $LD_LIBRARY_PATH should be native-only.
> >>But come to think of it, do remote targets even have environment
> >>variables?
> >
> >>And if so -- do they inherit them from gdb / the host?  If there's a
> >>gdbserver-type situation, and if the server is able to provide the true
> >>environment variables from the target, then yes, we should use these.
> >>But I don't recall any gdbserver ever offering that functionality.
> >
> > Our pdebug remote protocol allows us to 'set qnxinheritenv true/false'.
> > This determines whether gdb will send it's environment to the target or
> > whether the target will inherit from the pdebug server.
>
> Cool, and I presume you can then read them back.
> In that case, (assuming the child inherits from the target side server),
> wouldn't you want LD_LIBRARY_PATH to be searched?  If the linker-loader
> picks up libc from one place, but gdb picks it up from someplace else,
> you're hosed.

Nope.  Say I've got a windows host.  My libs are in $QNX_TARGET/$CPU/usr/lib
(ie. c:\QNXsdk\target\qnx6\ppcbe\usr\lib).  On my target, LD_LIBRARY_PATH is
relative to the root, on my host, they're relative to $QNX_TARGET/$CPU.
This is where the target defined search function comes in.  We construct a
search path using $QNX_TARGET/$CPU as a base and search from there.
Actually, we set solib-absolute-prefix to $QNX_TARGET/$CPU as well so in
many cases it gets found by the very first check.

cheers,

Kris