How can I find libraries to load them dynamically with dlopen

In the project I am working on, we provide the possibility to dynamically load additional features. For that we use dlopen.

To find this libraries we have something we call module path. There we have a default path, where the shared libraries are (a lot of them are shipped).

At the moment we have two default paths: we first look in the build directory for the shared library and afterwards in the install directory. This is because it should also be possible to run the application without installing it (so in that case it needs to look first in the build directory).

Now the problem ist, if a user builds the application from source and installs it with make install, the libraries in her build directory are loaded by default. This will result in a crash. So it only works if the user afterwards removes or renames the build directory.

No the question: is there a trick (either by C++ or by the build system) to know whether the application is installed or not. The problem is, that the functionality is implemented in a shared library and the implemented way to search for modules has to work also for other applications that l开发者_JS百科ink against our library (so we can not rely on the path of the executable). We use CMake as a build system.

To make the situation even harder, the solution has to work on Windows, Linux and Mac OS X.

EDIT:

I further investigated and the problem is more complicated. This is the situation:

• There is a small executable a
• Furthermore there is a "main" library main.so
• then there is a dynamically loaded library lib.so
• lib.so links against main.so

The problem is, that lib.so has the absolute path to main.so in the build directory in its rpath. Thanks to the tip of @MSalters I now was able to make a hack to make sure to load the correct version of lib.so (the one in the install directory) but since it has the build path in the rpath it loads the wrong main.so (so in fact there are two copies of main.so in the memory - this messes things up).

Is there a way to remove this reference to the build path from the library? I tried all options of cmake related to rpath without success

Can't you check where the executable itself is? If it's in the build directories, use build libraries -- if it's in the install, use install?

getcwd() has equivalents on all of those platforms, but it might not be what you want -- it depends on how you run the executable.

To get the process's location is system specific, I think, but it shouldn't be too hard to wrap that.

The installed version should not have the build directory in the rpath.

You might want to do the linking twice (once for the build version and once for the installed version). Usually, on *nix systems, the installed binary has some static path where it tries to find plugins. You might define some environment variable (or command-line argument) to overload it for the build execution (and use a wrapper script to set it in the build environment).

Check how it is solved by some projects (Firefox for example).

I don't know much about windows system but I think the standard way of doing this is to search plugins in the same directory as the executable.