1

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.

user2741831
  • 2,120
  • 2
  • 22
  • 43

1 Answers1

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.

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
  • I'm using eclipse cdt, so I 'll look a the output. thanks for your help – user2741831 Feb 10 '17 at 13:53
  • 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 – user2741831 Feb 10 '17 at 14:04
  • 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 ... – user2741831 Feb 10 '17 at 14:08
  • @user2741831 `-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. – Maxim Egorushkin Feb 10 '17 at 14:16
  • 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? – user2741831 Feb 10 '17 at 14:18
  • @user2741831 This is the second part of my answer: make sure you link with `-L/path/to -lmylib`, not with `-l/path/to/libmylib.so`. – Maxim Egorushkin Feb 10 '17 at 14:23
  • Oh, OK, I'll see how I set that up with eclipse – user2741831 Feb 10 '17 at 14:24
  • HEY IT WORKS. Thanks a ton m8 – user2741831 Feb 10 '17 at 14:33
  • @user2741831 I know, it does indeed! – Maxim Egorushkin Feb 10 '17 at 14:35