问题
I have the following Problem: I'm trying to create a portable version of my program, so I set rpath to "." so all libraries are linked using the relative file path. And this does work for all libraries except one. For some reason, the program only works if one specific library is present at the same position it was linked when it was compiled. Which is one I wrote myself, which also has its rpath set to ".". So basicly, the program will refuse to start even though the library is at the exact same position as the executable.
I have verified that only that one library is the problem, because if I create the folder in which the libary on my computer on the test computer, the program will start.
linux-vdso.so.1 => (0x00007ffcc5961000)
libOgreHlmsPbs.so.2.1.0 => ./libOgreHlmsPbs.so.2.1.0 (0x00007fedeec3f000)
libOgreHlmsUnlit.so.2.1.0 => ./libOgreHlmsUnlit.so.2.1.0 (0x00007fedeea1d000)
libOgreMain.so.2.1.0 => ./libOgreMain.so.2.1.0 (0x00007fedee194000)
/home/marvin/workspace/HLMS_DS_DEMO/libHLMS_DS.so => not found
So does anyone have an idea what could lead to linux trying to find the library at the original location instead of at the relative one like all the others? Also the Program works fine on windows.
回答1:
I set rpath to
.so all libraries are linked using the relative file path
Using . in rpath is a poor idea:
- Usability: the application must be run from a specific working directory.
- Security: an attacker may place modified
.sofiles in another directory and run your application from there.
The correct way is to use -rpath=$ORIGIN feature. See man ld.so:
$ORIGIN (or equivalently ${ORIGIN}) This expands to the directory containing the program or shared object. Thus, an application located in somedir/app could be compiled with
gcc -Wl,-rpath,'$ORIGIN/../lib'so that it finds an associated shared object in somedir/lib no matter where somedir is located in the directory hierarchy. This facilitates the creation of "turn-key" applications that do not need to be installed into special directories, but can instead be unpacked into any directory and still find their own shared objects.
$ORIGIN syntax is a bit unfortunate because it gets expanded as a variable by both make and bash, so you may need to quote it appropriately.
what could lead to linux trying to find the library at the original location instead of at the relative one like all the others
When linking, the library may be specified as -lmylib or -l:libmylib.so or -l<path>/libmylib.so. In the latter case the runtime linker looks for the library in that particular path <path>/libmylib.so only. See man ld, option -l for full details. You may like to review your build system linker commands.
来源：https://stackoverflow.com/questions/42158546/linux-c-trys-to-load-one-specific-library-using-an-absolute-path-while-all-ot