Recursive shared library loading - Cannot open shared object file

Question

I am compiling an application which consists of several projects, that generate dynamic libraries (Shared Libraries on LINUX). Of course that different projects are linking to the others that I've compiled. I am using CodeBlocks 10 under Ubuntu, using GCC compiler.

Due to the fact that, according to the arguments specified by the user, different libraries shall be loaded, in my main application I am loading the appropriate library, according to the decision, with the following line:

dll = dlopen("my_library.so", RTLD_LAZY);

As specified in documentation, the dlopen loads libraries automatically If the library has dependencies on other shared libraries and the process is done recursively.

The problem is that right after my dlopen, I call dlerror() in order to understand what's going on and I get the following error:

../../../../gccDebug/os.so : Cannot open shared object file: No such file or directory.

Just looking at the error, I completly understand it, because it is looking 2 folders below more than it should. The question is why?

What I mean is: I use relative paths to explicitly load Shared Libraries on the projects. On my Main Application, the Working Directory is ../../gccDebug. I load, using dlopen, mylibrary.so, which explicitly loads (in project Options) ../../gccDebug/gui.so. This gui.so then also explicitly loads (in project options) ../../gccDebug/so.os

What it seems to me that is happening, is that he is appending the paths making that on the 3rd "iteration" he is looking for a path which is already searching too many folders back than it should. If the first recursive loading (gui.so) works just fine, why does the 2nd recursive loading (so.os) is giving a strange path??

What is wrong with the recursive loading of the shared libraries using dlopen function?

Answer 1

Each path should be relative to the library doing the loading, so for ../../gccDebug/gui.so to load something in the same directory it should load ./gui.so

The extra ../.. are because you've told something in ../../gccDebug to load something in ../../gccDebug _relative to itself_ which relative to your program's working directory is ../../gccDebug/../../gccDebug ie ../../../gccDebug`

Do that a few times for different libraries and you'll get the number of unwanted .. components you're seeing.

Are you sure that gui.so actually loaded? Could it be that mylibrary.so had copied the ../../gccDebug/os.so dependency from gui.so at link-time and so at run-time was trying to load that before loading gui.so ?

Have you use ldd mylibrary.so to see what it tries to find? You can also use readelf -d mylibrary.so to see the contents of the dynamic section of the library.