DynamicLibrarySearchPaths
From Apache OpenOffice Wiki
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 theprogram
directory:libstdc++.so
(issue 78390) andpython.bin
(issue 78406). Only relevant for StarOffice, some StarOffice-only dynamic libraries also lack anRPATH
(and additionally referencesal
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 UREuno
executable guarantees that components loaded into it find all relevant URE libraries preloaded, but other executables (at leastregcomp
,soffice
, andunopkg
; maybe more) do not give that guarantee. - At least relevant for
unxlngi6
,unxsoli4
, andunxsols4
, the public dynamic librariescppu
,cppuhelper
,sal
, andsalhelper
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.
- At least relevant for ELF, some objects lack an
- 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 removejavaldx
on Mac OS X.