forked from amazingfate/loongoffice
9990e98d67
The problem is that python modules (*.pyd) find DLLs in the wrong
places.
This is because sal_detail_initialize() calls SetDllDirectoryW(""),
which removes (sometimes?) the "current directory" from the DLL
search order, which is deliberately initialized to the "program"
dir by CreateProcess() calls in officewrapper.cxx.
Loading DLLs still works for LO's own DLLs since they are all
in the "program" directory, which is the same directory where
all the executables are, so it is searched first.
But CPython loads its modules with LOAD_WITH_ALTERED_SEARCH_PATH,
which doesn't search the directory of the executable but
the directory of the immediately loaded DLL i.e. the *.pyd file
instead, i.e. python-core-X.Y.Z/lib.
It would be possible to call SetDllDirectory(".../program")
instead but probably that would require patching python
since it needs to be done in the real exectuable, not in
the wrapper executable.
So overwrite the $PATH again (like was done in the days of
the office of the holy trinity) in the officewrapper.cxx and
genericloader.cxx to prepend "program" and get priority
over the rest of $PATH.
This still doesn't protect against C:/Windows/System32/LIBEAY32.DLL
since that has higher priority than $PATH but hopefully nobody
is *that* stupid.
This patch fixes soffice.exe, swriter.exe etc., and unopkg.exe.
The python.exe wrapper already prepends "program" to $PATH.
Change-Id: If03f07eba9a2c7fc6cf44f82f639b5d0b4c62e20
What used to be the desktop in StarOffice 5 - now the binary.
Stable Interface
================
Some of the artifacts built here are part of a LibreOffice installation set's
stable interface, which (programmatic) clients can depend on. Among them are:
soffice
=======
In the "program" directory ("program/" on Linux and Windows, "Contents/MacOS/"
on Mac OS X).
unoinfo
=======
In the "program" directory ("program/" on Linux and Windows, "Contents/MacOS/"
on Mac OS X).
When called with a sole argument of "c++", it prints to stdout an absolute
pathname denoting the directory where the public URE libraries are found.
When called with a sole argument of "java", it prints to stdout a marker
character (either an ASCII '0' or '1') followed by a sequence of zero or more
absolute pathnames denoting jars or directories that need to be included in a
class loader's search locations.
If the marker character is '0' (on Linux and Mac OS X), the pathnames are
encoded as bytes, and any two pathnames in the sequence are separated from each
other by NUL bytes.
If the marker character is '1' (on Windows), the pathnames are encoded as
UTF-16-LE two-byte code units, and any two pathnames in the sequence are
separated from each other by two-byte NUL code units.