This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Why does solib_open do what it does?
> >>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