[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rpath stripping
From: |
Richard Purdie |
Subject: |
Re: rpath stripping |
Date: |
Mon, 18 Apr 2022 14:41:49 +0100 |
User-agent: |
Evolution 3.40.4-1ubuntu2 |
On Mon, 2022-04-18 at 07:39 -0400, Carlos O'Donell wrote:
> On 4/17/22 10:06, Bob Friesenhahn wrote:
> > The libtool I was using (originating from Ubuntu Linux) stripped the
> > rpath (which was provided like '-Wl,rpath=/usr/lib') so I was unable
> > to embed an rpath in the libcurl I built so that applications linked
> > with that libcurl would find it.
>
> I agree with our position.
>
> The behaviour of stripping '-Wl,-rpath' is incorrect.
>
> With new DT_RUNPATH semantics (DT_RPATH being deprecated and binutils having
> switched defaults), each shared object, including the binary, must correctly
> specify the search path for the immediate needed objects. Stripping this off
> will result in incorrectly built shared objects and binaries that don't
> operate correctly.
>
> I'm curious what justification is given for this behaviour.
As I understand it the dynamic loader has a set of search paths it falls back to
(sys_lib_dlsearch_path in libtool). An RPATH or RUNPATH entry matching a system
loader path isn't usually of much use, it just takes up space.
I can imagine some cases where that might not be true such as linking with "-z
nodeflib" or some fairly convoluted setups but I suspect those would have other
issues too.
Cheers,
Richard