On 07.03.2017 14:42, Stephan Bergmann wrote: > On 03/05/2017 11:54 AM, Stephan Bergmann wrote: >> commit f764d67da42caa71fd5e02146b1ca32680ae2f6e >> Author: Stephan Bergmann <sberg...@redhat.com> >> 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:
eeeek [...] > 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. i think this problem is better solved in gb_LinkTarget__use_gpgmepp like commit ee9cb85e9adc03693141a106630a4f278b4e93ac. probably that's how it works for other externals? _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
