Yrurtj

I have an executable app, which depends on a library libbar.so and loads it via RPATH with $ORIGIN like this:

$ readelf -d app



Dynamic section at offset 0xe08 contains 26 entries:

  Tag        Type                         Name/Value

 0x0000000000000001 (NEEDED)             Shared library: [libbar.so]

 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/lib/]

It would be nice to run it in the appropriate directory structure, made with symlinks to the executable and the libbar.so:

$ ls -R

.:

app@  lib/



./lib:

libbar.so@

-- but the linker follows symlinks to the original file of the executable, sets $ORIGIN to the directory of the executable file and resolves the dependency paths from there. Is it possible to make it not do this? So that directory-path-wise, in the search for lib files, the symlinks are treated as real files of the filesystem ("end-points" of the search).

Also, some reasoning to this problem:

1. It is convenient to have binaries set up to search for dependencies in a couple relational directories, for instance in the $ORIGIN/ of a binary itself and also in $ORIGIN/appname_dependencies/ (so that one can just copy the binary and its' dependencies into one directory and run it, but also has a fall-back for a more complicated set-up with multiple versions of the same binary in the system).




2. Due to the requirement of several dependency search paths, RPATH is the search method to use: a "slashed" name of dependency (NEEDED Shared library: [./libbar.so]) sets only 1 search path. Also, for simplicity the dependency resolution paths should be in the binary itself.



3. 
   

   It's nice to be able to combine all binaries (the application and all its' dependencies) into the full dependency graph with links, instead of copying the files. And symbolic links are more resilient than hard links: they link across filesystems. In fact, I have this problem in one academic environment of a linux cluster, where a hard link to parent directory cannot be done:

   
   
   

       $ ln ../afile 
   
       ln: creating hard link `./afile' => `../afile': Invalid cross-device link
   
   

   
   

If you really want to mix symbolic links like that, you could construct a configuration like this:

• move your executable to its own directory


• make a symbolic link from the "normal" location to the moved executable


• create symbolic links in the executable's directory to the shared libraries that you want to resolve