Why are the dll-path and hardcode-dll-paths
properties useful?

Note

This entry is specific to Unix systems.

Before answering the questions, let us recall a few points about shared
libraries. Shared libraries can be used by several applications, or other
libraries, without physically including the library in the application
which can greatly decrease the total application size. It is also possible
to upgrade a shared library when the application is already installed.

However, in order for application depending on shared libraries to be
started the OS may need to find the shared library when the application is
started. The dynamic linker will search in a system-defined list of paths,
load the library and resolve the symbols. Which means that you should
either change the system-defined list, given by the LD_LIBRARY_PATH
environment variable, or install the libraries to a system
location. This can be inconvenient when developing, since the libraries
are not yet ready to be installed, and cluttering system paths may be
undesirable. Luckily, on Unix there is another way.

An executable can include a list of additional library paths, which will
be searched before system paths. This is excellent for development because
the build system knows the paths to all libraries and can include them in
the executables. That is done when the hardcode-dll-paths
feature has the true value, which is the
default. When the executables should be installed, the story is different.

Obviously, installed executable should not contain hardcoded paths to your
development tree. (The install rule explicitly disables the
hardcode-dll-paths feature for that reason.) However,
you can use the dll-path feature to add explicit paths
manually. For example:

will allow the application to find libraries placed in the
/usr/lib/snake directory.

If you install libraries to a nonstandard location and add an explicit
path, you get more control over libraries which will be used. A library of
the same name in a system location will not be inadvertently used. If you
install libraries to a system location and do not add any paths, the
system administrator will have more control. Each library can be
individually upgraded, and all applications will use the new library.

Which approach is best depends on your situation. If the libraries are
relatively standalone and can be used by third party applications, they
should be installed in the system location. If you have lots of libraries
which can be used only by your application, it makes sense to install them
to a nonstandard directory and add an explicit path, like the example
above shows. Please also note that guidelines for different systems differ
in this respect. For example, the Debian GNU guidelines prohibit any
additional search paths while Solaris guidelines suggest that they should
always be used.