Re: rpath stripping
On Mon, 18 Apr 2022, Richard Purdie wrote: 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. It is of use since it influences the search order. For example, if /usr/local/lib is in the system loader path, and the user installs a library in /usr/local/lib, then the user likely wants the library she has just installed to be used by apps which link with it, rather than some similar library in the default system loader path. Likewise, it is pointless to install a library which will never be used. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
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
Re: rpath stripping
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. -- Cheers, Carlos.
