[Libreoffice-commits] core.git: Fix Executable_pdfverify dependencies on Linux

[Stephan Bergmann]

On 03/05/2017 11:54 AM, Stephan Bergmann wrote:
> commit f764d67da42caa71fd5e02146b1ca32680ae2f6e
> Author: Stephan Bergmann <sbergman at 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:

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.