Linux C++ trys to load one specific library using an absolute path, while all otheres are linked using a relative one

Question

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.

Popup

Do you want to set rpath relative to current directory ($PWD) or relative executable location? – Englert

Why don't just follow -I rules? GCC Directory Options – Solanum

relative the executable location optimally – Popup

Post the complete command lines that build your application. Copy-paste that from Eclipse output. – Juieta

Its ok its solved, thanks for the help – Popup

Answer 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 .so files 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.

Juieta

I'm using eclipse cdt, so I 'll look a the output. thanks for your help – Popup

this doesn't help, I want a portable application, meaning the user needs to be able to put the folder anywhere he wants and just execute the program. Its used internally so don't worry, I'll look at the rest of your answer, to see if that helps – Popup

I just tried Ldd, but weirdly, every single other library is loaded dynamicly, while mine is loaded with an absolute path, I posted the output ... – Popup

@Popup -rpath=$ORIGIN is what you need mate, this is how all commercial Linux applications are linked. You need to be able to understand the documentation though. – Juieta

Then I must have done it wrong, because I did build the application with rPath="$Origin" but it still linked the library to the path the appliaction was when it was compiled, when I checked with ldd. Or do I neded to build the library with rpath Origin aswell? – Popup

@Popup This is the second part of my answer: make sure you link with -L/path/to -lmylib, not with -l/path/to/libmylib.so. – Juieta

Oh, OK, I'll see how I set that up with eclipse – Popup

HEY IT WORKS. Thanks a ton m8 – Popup

@Popup I know, it does indeed! – Juieta