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

classic Classic list List threaded Threaded
5 messages Options
sberg sberg
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

On 03/05/2017 11:54 AM, Stephan Bergmann wrote:

> commit f764d67da42caa71fd5e02146b1ca32680ae2f6e
> Author: Stephan Bergmann <[hidden email]>
> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Stahl-2 Michael Stahl-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

On 07.03.2017 14:42, Stephan Bergmann wrote:

> On 03/05/2017 11:54 AM, Stephan Bergmann wrote:
>> commit f764d67da42caa71fd5e02146b1ca32680ae2f6e
>> Author: Stephan Bergmann <[hidden email]>
>> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

On 03/10/2017 05:21 PM, Michael Stahl wrote:
> i think this problem is better solved in gb_LinkTarget__use_gpgmepp like
> commit ee9cb85e9adc03693141a106630a4f278b4e93ac.
>
> probably that's how it works for other externals?

Ah thanks; indeed, using gb_LinkTarget_use_package in
RepositoryExternal.mk, that's apparently the prior art I failed to see
when looking for it.

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Thorsten Behrens-6 Thorsten Behrens-6
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Stephan Bergmann wrote:
> On 03/10/2017 05:21 PM, Michael Stahl wrote:
> > probably that's how it works for other externals?
>
> Ah thanks; indeed, using gb_LinkTarget_use_package in RepositoryExternal.mk,
> that's apparently the prior art I failed to see when looking for it.
>
Idly wondering - is there some subset of commits we could extract as
'current best practice to add external lib'?

Cheers,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (968 bytes) Download Attachment
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

tdf#34654 inline gbuild documentation (was: Fix Executable_pdfverify dependencies on Linux)

Hi,

On Fri, Mar 17, 2017 at 01:05:25AM +0100, Thorsten Behrens wrote:
> Idly wondering - is there some subset of commits we could extract as
> 'current best practice to add external lib'?

soo, ... as the discussion of up-to-date documentation of the build system came
up again and again recently, allow me to point you to the current work on
tdf#91387:

 https://gerrit.libreoffice.org/#/c/34654/

which is to allow generating gbuild docs from inline comments. I assume (and
hope) that this might make the fly-by creation of docs for the build system
more likely: So far nobody bothered much writing e.g. a wiki page on build
system best practices and kept it up to date.

As I'd be one of the three guys (mst, dtardon and me wrote most of gbuilds
lines) least likely to be in need of explicit docs, Im not the best person to
review the _result_ for usefulness (I might expand inline documentation to the
best of my knowledge once this is in place though).

So -- anyone requesting better build system docs, feel invited to review and
mentor on the above change.

Best,

Bjoern
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Loading...