If your application has per-user libraries or modules, they should be put in the application directory in the users home directory, $HOME/.myapp/lib/
for example. If there are ancillary libraries in strange places, run your application with $HOME/.myapp/lib/
appended to LD_LIBRARY_PATH
, and let the user decide how to manage their libraries.
In Linux, handling shared libraries is quite well standardized. There's ldconfig
utility managing /etc/ld.so*
files to configure exactly where the libraries may reside, and of course LD_LIBRARY_PATH
to add special cases. Dynamic libraries are versioned, with the default symlinked to the latest version. (Okay, some libraries have goofed in not bumping the version number at the proper time, but that's another matter.) Applications are expected to adhere to this information, and not go out of their way to do something else.
How does this work, then?
Assume the user has a special module in $HOME/.myapp/lib/
, which requires a number of libraries scattered all over, none of them in the expected places. If your application was executed with $HOME/.myapp/lib/
, the user only needs to add symlinks in $HOME/.myapp/lib/
to point to the wayward libraries.
Your application does nothing special.
It uses just the library filenames without paths in the dlopen()
And please, do not write an application which dynamically edits those symlinks; it's just weird and suspect behaviour. I'd personally never use such a badly behaving application.
You could, however, write a separate configurator tool, which uses e.g. ldd
tools with e.g. find
, the user can use to locate the libraries and manage the needed symlinks. But I don't believe the users will actually need one.