This is the mail archive of the
mailing list for the binutils project.
Re: Should ld consider -rpath '$ORIGIN' when finding dependencies?
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Thu, 2 May 2013 21:42:04 +0100
- Subject: Re: Should ld consider -rpath '$ORIGIN' when finding dependencies?
- References: <CAH6eHdSMJ+CZ2GX_oUBHo6V18UvXoNd4W52PWcSV69uWrOzE+g at mail dot gmail dot com> <CAMe9rOr5gA-nPOVgQpu2hC6x4rPJzKa6nb2fRgSaRo8Vo4JCBg at mail dot gmail dot com>
On 2 May 2013 21:04, H.J. Lu wrote:
> On Thu, May 2, 2013 at 12:29 PM, Jonathan Wakely <firstname.lastname@example.org> wrote:
>> So is this a ld bug, or just a difference between bfd and gold?
>> I expected this to work given that ./libbar.so contains
>> DT_RPATH=$ORIGIN and ./main is being given DT_RPATH=$ORIGIN too, both
>> of which would allow finding ./libfoo.so at runtime, so I expect it to
>> link successfully.
> Since the build directory layout is independent of the run-time directory
> layout, checking $ORIGIN may not always work at build time.
Right, but in my case my build directory structure exactly mirrors the
deployment directory structure, precisely so that RPATHs work both in
development and when deployed to production and I don't need to mess
around with LD_LIBRARY_PATH.
The link succeeds if there is some other libfoo.so e.g. in another
directory in LD_LIBRARY_PATH, even though that's *not* the one that
will be used at run-time.
> BTW, gold doesn't check undefined symbols in libbar.so.
Ah, so it "works" with gold because it doesn't do the check.
It seems this isn't a bug, so I'll use -rpath-link in addition to
-rpath so the library will be found at link-time.
Thanks for the quick response.