Re: rpath stripping

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