I'm linking an executable, on Linux (SuSE version 9.1, kernel version 2.6.6, ld version 2.15.90.0.1.1, gcc version 3.2.3 (old)), and I want to augment the shared library path used by dlopen(). In the manpage on that system, it says that, in addition to all the standard places to look, dlopen() will use DT_RUNPATH or fall back on DT_RPATH.
During the link (I use gcc as a front-end to ld), I specify '-Wl,-rpath,LOCATION' (equivalent to calling ld w/ '-rpath LOCATION'), among other options, yet dlopen() fails to find the library in LOCATION. On an older system (SuSE version 9.0, kernel version 2.4.21, ld version 2.14.90.0.5, gcc version 3.2.3 (same)), dlopen() succeeds. On either system, if I put LOCATION in LD_LIBRARY_PATH, dlopen() succeeds, yet that's an unreasonable requirement for this application.
I'm aware of the tool chrpath (
http://freshmeat.net/projects/chrpath/?topic_id=46), but I want to know if there's a more straight-forward way to set DT_RUNPATH. Such as via the command-line for ld.
BTW, isn't it a bit strange that someone had to write a dedicated tool for doing that? Is it really true that binutils contains nothing for dumping or modifying DT_RPATH or DT_RUNPATH (or similar labels)?
for sh/ksh/bash
you do:
DT_RUNPATH=/path-to/lib
export DT_RUNPATH
or simply use LD_LIBRARY_PATH
LD_LIBRARY_PATH=${LD_LIBRA
export LD_LIBRARY_PATH
For csh/tcsh
setenv LD_LIBRARY_PATH $LD_LIBRARY_PATH:/path-to-
you can you them in your .profile (sh/ksh/bash) or .cshrc file (csh/tcsh)