On 03/05/2017 11:54 AM, Stephan Bergmann wrote:
commit f764d67da42caa71fd5e02146b1ca32680ae2f6e
Author: Stephan Bergmann <[email protected]>
Date: Sun Mar 5 11:54:05 2017 +0100
Fix Executable_pdfverify dependencies on Linux
Change-Id: Idf5561baaa714834e8e763e379a79d084e21dc80
diff --git a/xmlsecurity/Executable_pdfverify.mk
b/xmlsecurity/Executable_pdfverify.mk
index 9a67a78..9364e39 100644
--- a/xmlsecurity/Executable_pdfverify.mk
+++ b/xmlsecurity/Executable_pdfverify.mk
@@ -34,4 +34,16 @@ $(eval $(call gb_Executable_add_exception_objects,pdfverify,\
xmlsecurity/workben/pdfverify \
))
+# Library_xmlsecurity links against Library_xsec_gpg (on certain OS), which
+# links against gpgmepp dynamic library from external project gpgmepp, which
+# (for non-SYSTEM_GPGMEPP) is delivered to instdir/program in
+# ExternalPackage_gpgme, and at least the Linux linker wants to see all
+# (recursively) linked libraries when linking an executable:
+ifneq ($(filter-out WNT MACOSX ANDROID IOS,$(OS)),)
+ifneq ($(SYSTEM_GPGMEPP),TRUE)
+$(call gb_Executable_get_target,pdfverify): \
+ $(call gb_ExternalPackage_get_target,gpgme)
+endif
+endif
+
# vim:set noet sw=4 ts=4:
So I expected there would be more problems like this hidden around,
where (on Linux, at least) an executable gets built that links against a
dynamic library that in turn links against a dynamic library delivered
from some ExternalPackage. But running the script
my_clean=
for i in $(ls external/*/ExternalPackage_*.mk); do
my_clean="$my_clean $(basename "${i%.mk}").clean"
done
for i in $(find . -name Executable_\*.mk); do
make -O -j4 -k $my_clean >/dev/null 2>&1
i=$(basename "${i%.mk}")
echo "==== BUILDING $i:"
make -O -j4 "$i".clean && make -O -j4 "$i"
done
(which, for every Executable first cleans all ExternalPackages and then
tries to build the Executable; it misses out on some executables where
the spelling of the file name doesn't match the gb_Executable name, as
in shell/Executable_uri_encode.mk vs.
gb_Executable_Executable,uri-encode)---apart from taking surprising long
to run---didn't find any further cases of such missing dependencies. So
either there really aren't any, or my /usr/lib64 happened to contain
enough libraries to erroneously and silently satisfy all the other demands.
_______________________________________________
LibreOffice mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
