DynamicLibrarySearchPaths

On all the Unix-like platforms, many start scripts (at least OOo configimport, gengal, pkgchk, python, python.sh, setofficelang, soffice, spadmin, uno, and unopkg; SDK regcomp; and URE regcomp, startup.sh, and uno; and maybe more) add to the (platform specific: LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, etc.) dynamic library search path, for various reasons. The goal should be to minimize this, ideally removing it completely.

• Some scripts add the OOo program directory, for various reasons:
  • At least relevant for ELF, some objects lack an RPATH even though they depend on dynamic libraries in the program directory: libstdc++.so (issue 78390) and python.bin (issue 78406). Only relevant for StarOffice, some StarOffice-only dynamic libraries also lack an RPATH (and additionally reference sal etc. without the “uno_” prefix, see below).
  • Native UNO components loaded in-process may depend on the public URE dynamic libraries (sal etc.), but typically cannot know where to find those libraries relative to their own location (as, e.g., UNO components that are part of an OOo extension are deployed into some deep, opaque directory hierarchy). The URE uno executable guarantees that components loaded into it find all relevant URE libraries preloaded, but other executables (at least regcomp, soffice, and unopkg; maybe more) do not give that guarantee.
  • At least relevant for unxlngi6, unxsoli4, and unxsols4, the public dynamic libraries cppu, cppuhelper, sal, and salhelper were renamed for OOo 2.0 (adding a “uno_” prefix), keeping the old names available as symbolic links. Even if the above issue were addressed, old native UNO components that depend on the old library names would still pose a problem (unless the relevant libraries were also preloaded with their old names, if possible). See issue 77188 for an example.
  • SDK executables completely rely on the dynamic library search path to locate dependent libraries.
• Some scripts add a system wide directory in which the Mozilla libnss3.so can be found.
• Some scripts add the output of javaldx, to work around limitations of certain JRE implementations where dynamic libraries of the JRE fail to find other dynamic libraries of the JRE they depend on. See issue 78999 to remove javaldx on Mac OS X.