Re: Passing LD_RUN_PATH through to the linker

[Tim Rice]

Kevin,

On Wed, 14 Dec 2022, Kevin R. Bulgrien wrote:

> During attempts to build top-of-tree libssh2 on a dinosaur (SCO OpenServer 
> 5.0.7),
> an issue with loading indirect dependencies of libssh2.so is occurring.  They 
> can
> be worked around by setting LD_LIBRARY_PATH at run-time, however it seems much
> simpler to depend on DT_RPATH so the run-time environment does not require
> management.
> 
> The linker behaves as defined at the link following (ironically, more 
> completely
> documented on this list than in the official documentation):
> 
>   https://lists.gnu.org/archive/html/bug-libtool/2002-08/msg00026.html
> 
[snip]
> 
> Can anyone offer a pointer on where to look in autotools/libtool structure
> to get DT_RPATH set in the linked binaries or comment on whether this is
> even an option with libtool?   I'm finding difficulty differentiating
> between -R and -rpath for libtool versus similar switches for ld.

On OpenServer, I usually just build with the SONAME being a full path name.

I am attaching a patch to the libtool 2.4.6 generated during
a libssh2-1.8.0 build.

Once all testing is complete, I do
......
rm src/libssh2.la
SCOABSPATH=1 ; export SCOABSPATH
gmake 2>&1 | tee x.log
......
then package.

Note: the last hunk is to address a regression introduced in 2.4.6
with the freebsd reorg.

-- 
Tim Rice                                Multitalents
tim@multitalents.net

libtool-2.4.6-fullpath-soname.patch
Description: libtool-2.4.6-fullpath-soname.patch