Apache OpenOffice (AOO) Bugzilla – Issue 101244
Windows: move all DLLs into brand program directory
Last modified: 2009-10-09 08:11:46 UTC
Unlike on other platforms, spreading DLLs across the three layers has no real benefits on Windows (and was mainly done for consistency across platforms), but instead on the one hand causes problems (like issue 94226) and on the other hand degrades performance (see <http://wiki.services.openoffice.org/w/index.php?title=Performance/Library_and_directory_structure&oldid=120824>).
.
Issue 101570 is probably another problem similar to issue 94226 (with ICU instead of libxml2) that could eventually be solved by this change.
*** Issue 101570 has been marked as a duplicate of this issue. ***
fixed on cws/sb110 (only moving DLLs from Basis layer, not from URE layer, to avoid incompatible changes to OOo's external interface); relevant commits: r271682: read configmgr ini file explicitly from $OOO_BASE_DIR/program (instead of next to configmgr dynamic library) r271683: take odbcconfig.exe explicitly from $OOO_BASE_DIR/program (instead of implicitly next to some dynamic library) r271684: take senddoc.exe explicitly from $OOO_BASE_DIR/program (instead of implicitly next to some dynamic library) r271685 take legacy_binfilters.rdb explicitly from $OOO_BASE_DIR/program (instead of implicitly next to some dynamic library); cleaned up dead code r271686 support NativeServicesURLPrefix on individual files; to implement that, changed meaning of global unomaxservices r271702 hardwire Python dynamic libraries and script files into base layer (even if other dynamic libraries will move to brand layer on Windows), mainly because the pyuno dynamic library is both linked against from other dynamic libraries (pythonloader.uno) and accessed via "import pyuno" from Python scripts r271703 for performance reasons, on Windows move DLLs from basis to brand layer (i.e., next to executables); consequently eliminated some library duplications across the layers; adapted various code to the move r271712 after DLLs have been moved from basis to brand layer on Windows, code that used SvtPathOptions::GetModulePath to located libraries had to be adapted
*** Issue 96132 has been marked as a duplicate of this issue. ***
@jsk: Please verifiy that - on Windows, almost all DLLs from basis-layer program directory have moved to brand-layer program directory; - there are no regressions on Windows resulting from the move (esp. in code that is triggered from outside, like system integration or Mozilla integration, or triggers outside code, like mail merge). - on other platforms, nothing has changed (the libraries are still in the basis-layer program directory, and there are no regressions).
Mail Merge -> Test E-Mail settings is broken.
Setting back to fixed - i managed to unveil a logic error in the user interface which will certainly harm one in a billion users.
Verified
Close