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/


-- 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
  • Are hard links a possibility? Aug 10, 2016 at 16:44
  • @SatyaMishra sadly no. Hard links work indeed splendidly -- they are just like regular files for the filesystem, but don't take more space -- and that's what I need. But it would be better to have symbolic links, since they can link to files across devices/filesystems.
    – xealits
    Aug 10, 2016 at 17:00

1 Answer 1


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
  • but that is exactly what I want to avoid: executable file sitting in a directory together with some particular dependency libraries, so that the dependency graph is already defined. I would like to have a directory with executables and libraries of any versions, with not colliding names (hash of the content of the binary file), and the whole dependency graph could be constructed with links to particular binaries.
    – xealits
    Aug 11, 2016 at 23:06
  • The libraries don't have to be in that directory. That's what I pointed out in my answer. Alternatively, you could rewrite the dynamic loader. Aug 11, 2016 at 23:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .