summaryrefslogtreecommitdiff
path: root/desktop/Executable_soffice.mk
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2012-03-19 14:18:51 +0100
committerStephan Bergmann <sbergman@redhat.com>2012-03-19 14:21:00 +0100
commit9019ccb42398b714666f045693e503780d9746ab (patch)
tree3eeaafd78d4da45f32a247aa9c0e6418949c5a38 /desktop/Executable_soffice.mk
parentf3e4e3ea9424fee25ddded30247a8e884ac4bd94 (diff)
soffice.exe must not link against sal3.dll (might fix fdo#44489)
...as soffice.exe creates the proper environment (PATH) for soffice.bin to be able to load URE libs like sal3.dll, so soffice.exe itself should neither be able to load nor depend on sal3.dll (and does not depend on anything exported by it, anyway). It is unclear to me how this ever worked (which it presumably did?) with any Windows build, either native MSVC or cross-compiled MinGW. (Maybe MSVC builds do not record a dependency from soffice.exe to sal3.dll, noting that the former does not import anything from the latter?)
Diffstat (limited to 'desktop/Executable_soffice.mk')
-rw-r--r--desktop/Executable_soffice.mk1
1 files changed, 0 insertions, 1 deletions
diff --git a/desktop/Executable_soffice.mk b/desktop/Executable_soffice.mk
index b1698985401a..9ca4d3a0345c 100644
--- a/desktop/Executable_soffice.mk
+++ b/desktop/Executable_soffice.mk
@@ -30,7 +30,6 @@ $(eval $(call gb_Executable_Executable,soffice))
$(eval $(call gb_Executable_set_targettype_gui,soffice,YES))
$(eval $(call gb_Executable_add_linked_libs,soffice,\
- sal \
advapi32 \
shell32 \
shlwapi \