I have an executable
app, which depends on a library
libbar.so and loads it via
$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
$ 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:
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).
Due to the requirement of several dependency search paths,
RPATHis 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.
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