Typically an unbundled product is designed to be installed in a standalone, unique location. This product is composed of binaries, shared object dependencies, and associated configuration files. For example, the unbundled product ABC might have the following layout:
Let's assume that the product is designed for installation under /opt. Normally a user will be required to augment their PATH with /opt/ABC/bin so as to locate the product's binaries. Each binary will locate their dependencies using a hard-coded runpath within the binary. For the application abc
it would be:
% dump -Lv abc [1] NEEDED libA.so.1 [2] RPATH /opt/ABC/lib |
and similarly for the dependency libA.so.1 this would be:
% dump -Lv libA.so.1 [1] NEEDED libB.so.1 [2] RPATH /opt/ABC/lib |
This dependency representation works fine until the product is installed in some directory other than the recommended default. If a different installation is created, users must resort to LD_LIBRARY_PATH to run the product's applications. Often this is brought about by the introduction of wrappers for each binary, and sometimes inventive souls have even tried modifying the runpath within the appropriate objects.