This is the mail archive of the
mailing list for the GDB project.
Re: GDB honouring RPATH in binaries.
> > I've been having a debate with some coworkers about whether or not gdb
> > should use the rpath in an elf binary to find shared libs if it has been
> > set. The runtime loader checks LD_LIBRARY_PATH, RPATH and CS_LIBPATH in
> > that order and the proposal was that gdb should do the same thing.
> > The problem I have with this is in the remote case. This might make
> > sense on a self-hosted debugger but if targetting a remote machine, the
> > RPATH might not make any logical mapping onto the host machine's
> > It might be possible to come up with some sort of heuristic using
> > solib-absolute-prefix as a base but I don't think there's any reliable
> > to make use of this info if not self hosted.
> > Any thoughts?
> The other problem that I see is that the procedures used to resolve
> the location of a dynamic library will vary depending upon the runtime
> loader. E.g, on Linux, I am pretty sure that RPATH supercedes
> It may make sense to have a osabi dependent method for doing this
> resolution. Or maybe this machinery should be tied to the solib
> back end. (That way if you had a qnx back end, it would get used
> With regard to the remote case, I would have thought that simply
> prepending solib-absolute-prefix would give the correct results.
Well, let's say I upload my program and libs to /tmp on the remote with the
binary's RPATH set to /tmp. I'm debugging on Cygwin in /home/kewarken/test.
My solib-absolute-prefix and solib-search-path are based in
c:\QNXsdk\target\qnx6 (where all the libs are stored). This is why I'm not
convinced that there's any nice way to use RPATH in the remote case.