Quote Originally Posted by Ginsengelf View Post
Hi, my guess my addLibraryPath() does not work as you expect is that the dependencies of your plugin are not handled by your Qt program (where you called addLibraryPath), but by the "normal" procedure, which relies on LD_LIBRARY_PATH and does not know about the addLibraryPath() call.

One alternative could be that you use static linking to link libTestLib.so.1 (or the corresponding .a file) to your plugin.
As for your "guess", this matches my observation. My expectation was, however, that when loading the shared library the Qt code somehow updates the LD_LIBRARY_PATH variable locally, then loads the library (with the typical linux-style dlopen() call and restores the environment variable afterwards. However, this won't work, as the man page for dlopen() clearly states:

• If, at the time that the program was started, the environment
variable LD_LIBRARY_PATH was defined to contain a colon-
separated list of directories, then these are searched. (As a
security measure, this variable is ignored for set-user-ID and
set-group-ID programs.)
So, as there is no other way to tell dlopen() where to search for (indirectly linked) shared libs, my setup won't work on Linux.

As for the suggestion to link all dependent libraries statically, this is - unfortunately- not possible in all cases due to licensing restrictions.

The only remaining option I see here is to somehow edit the DT_RUNPATH ELF variable in my library, as this seems to be the only remaining way to tell ldopen() where to search for libraries.
Anyway, this is not a Qt issue (anylonger), hence I'm closing the topic.