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
