* GDB shared library tests with remote target
@ 2012-04-22 17:57 Michael Eager
2012-04-22 19:30 ` Andreas Schwab
2012-04-23 17:40 ` Daniel Jacobowitz
0 siblings, 2 replies; 6+ messages in thread
From: Michael Eager @ 2012-04-22 17:57 UTC (permalink / raw)
To: gdb
The gdb test suite contains a claim in gdb.exp:skip_shlib_tests
that the shared library tests should work for a variety of remote
targets, including Linux.
When gdb compiles the executable, it uses absolute paths to the
shared libraries. The linker is passed "-rpath $ORIGIN" which
effectively adds the directory containing the executable to the
library search path at run time.
When run on a remote system, the test fails to load the shared
library because the loader has an absolute path to the shared
library and does not search for it.
It doesn't look to me like this could ever work. The only way
(AFAIK) to have the linker put in a relative path to the shared
library is to run the link step in the build directory and use
a relative path, not an absolute path.
Q. Is there any option to tell the linker not to put a full
path in DT_NEEDED?
Q. Did this ever work? If yes, how and how do I make it work now?
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: GDB shared library tests with remote target
2012-04-22 17:57 GDB shared library tests with remote target Michael Eager
@ 2012-04-22 19:30 ` Andreas Schwab
2012-04-22 19:40 ` Michael Eager
2012-04-23 17:40 ` Daniel Jacobowitz
1 sibling, 1 reply; 6+ messages in thread
From: Andreas Schwab @ 2012-04-22 19:30 UTC (permalink / raw)
To: Michael Eager; +Cc: gdb
Michael Eager <eager@eagerm.com> writes:
> When gdb compiles the executable, it uses absolute paths to the
> shared libraries. The linker is passed "-rpath $ORIGIN" which
It is passed "-rpath \$ORIGIN" which puts $ORIGIN verbatim in the RPATH.
> effectively adds the directory containing the executable to the
> library search path at run time.
$ORIGIN is expanded *at run time*, pointing to the directory the
executable is located when executed.
> When run on a remote system, the test fails to load the shared
> library because the loader has an absolute path to the shared
> library and does not search for it.
If the shared library is located in the same directory as the executable
then it will be found due to $ORIGIN.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GDB shared library tests with remote target
2012-04-22 19:30 ` Andreas Schwab
@ 2012-04-22 19:40 ` Michael Eager
2012-04-22 21:07 ` Andreas Schwab
0 siblings, 1 reply; 6+ messages in thread
From: Michael Eager @ 2012-04-22 19:40 UTC (permalink / raw)
To: Andreas Schwab; +Cc: gdb
On 04/22/2012 12:30 PM, Andreas Schwab wrote:
> Michael Eager<eager@eagerm.com> writes:
>
>> When gdb compiles the executable, it uses absolute paths to the
>> shared libraries. The linker is passed "-rpath $ORIGIN" which
>
> It is passed "-rpath \$ORIGIN" which puts $ORIGIN verbatim in the RPATH.
That's what I said.
>> effectively adds the directory containing the executable to the
>> library search path at run time.
>
> $ORIGIN is expanded *at run time*, pointing to the directory the
> executable is located when executed.
That's exactly what I said, verbatim.
>> When run on a remote system, the test fails to load the shared
>> library because the loader has an absolute path to the shared
>> library and does not search for it.
>
> If the shared library is located in the same directory as the executable
> then it will be found due to $ORIGIN.
No, the DT_NEEDED path is used, since it has an absolute path.
If DT_NEEDED does not contain an absolute path, then the search
(including $ORIGIN) works.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GDB shared library tests with remote target
2012-04-22 19:40 ` Michael Eager
@ 2012-04-22 21:07 ` Andreas Schwab
0 siblings, 0 replies; 6+ messages in thread
From: Andreas Schwab @ 2012-04-22 21:07 UTC (permalink / raw)
To: Michael Eager; +Cc: gdb
Michael Eager <eager@eagerm.com> writes:
> No, the DT_NEEDED path is used, since it has an absolute path.
Ok, your mentioning of -rpath was confusing me.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GDB shared library tests with remote target
2012-04-22 17:57 GDB shared library tests with remote target Michael Eager
2012-04-22 19:30 ` Andreas Schwab
@ 2012-04-23 17:40 ` Daniel Jacobowitz
2012-04-23 17:58 ` Michael Eager
1 sibling, 1 reply; 6+ messages in thread
From: Daniel Jacobowitz @ 2012-04-23 17:40 UTC (permalink / raw)
To: Michael Eager; +Cc: gdb
On Sun, Apr 22, 2012 at 1:57 PM, Michael Eager <eager@eagerm.com> wrote:
> When run on a remote system, the test fails to load the shared
> library because the loader has an absolute path to the shared
> library and does not search for it.
> Q. Did this ever work? If yes, how and how do I make it work now?
I always run GDB tests with the same path on local and remote systems,
usually using NFS. Then it works. There's nothing fundamental about
this - you could teach all the affected tests to use a search path or
set sysroot or something - but this was easy at the time :-)
--
Thanks,
Daniel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GDB shared library tests with remote target
2012-04-23 17:40 ` Daniel Jacobowitz
@ 2012-04-23 17:58 ` Michael Eager
0 siblings, 0 replies; 6+ messages in thread
From: Michael Eager @ 2012-04-23 17:58 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
On 04/23/2012 10:39 AM, Daniel Jacobowitz wrote:
> On Sun, Apr 22, 2012 at 1:57 PM, Michael Eager<eager@eagerm.com> wrote:
>> When run on a remote system, the test fails to load the shared
>> library because the loader has an absolute path to the shared
>> library and does not search for it.
>
>> Q. Did this ever work? If yes, how and how do I make it work now?
>
> I always run GDB tests with the same path on local and remote systems,
> usually using NFS. Then it works. There's nothing fundamental about
> this - you could teach all the affected tests to use a search path or
> set sysroot or something - but this was easy at the time :-)
Yes, that seems to be the only way that this can work. Not easy
in the environment I'm working with.
BTW, it might be nice if the test suite contained tests using sysroot.
Fixing this doesn't require modifying all of the tests, only
gdb.exp:gdb_compile where the test is compiled.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-04-23 17:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-22 17:57 GDB shared library tests with remote target Michael Eager
2012-04-22 19:30 ` Andreas Schwab
2012-04-22 19:40 ` Michael Eager
2012-04-22 21:07 ` Andreas Schwab
2012-04-23 17:40 ` Daniel Jacobowitz
2012-04-23 17:58 ` Michael Eager
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).