libxml2: wrap xmllint to use the correct XML catalogues

Install a wrapper around xmllint in native builds to set
XML_CATALOG_FILES to the correct location of the XML catalogues, so that
the callers of this script (like xmlto) don't need to do the same.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 meta/recipes-core/libxml/libxml2_2.9.14.bb | 2 ++
 1 file changed, 2 insertions(+)

Hi,

this is a major change on behaviour and causing trouble at least for
KDE's kdoctools. Am no expert but I guess kdoctools uses custom
catalogs. Worked around trouble in meta-qt5-extra (assume meta-kf5
will face same) by preferring bare xmllint [1].
Just a heads up - it is about to land in kirkstone - have no idea what
this patch fixes.

[1] https://github.com/schnitzeltony/meta-qt5-extra/blob/master/recipes-kde/kf5/tier2/kdoctools/files/0002-Prefer-bare-xmllint.patch


Andreas

On Tue, Aug 23, 2022 at 5:37 PM Ross Burton <ross.burton@arm.com> wrote:
>
> Install a wrapper around xmllint in native builds to set
> XML_CATALOG_FILES to the correct location of the XML catalogues, so that
> the callers of this script (like xmlto) don't need to do the same.
>
> Signed-off-by: Ross Burton <ross.burton@arm.com>
> ---
>  meta/recipes-core/libxml/libxml2_2.9.14.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-core/libxml/libxml2_2.9.14.bb b/meta/recipes-core/libxml/libxml2_2.9.14.bb
> index e58298d3b01..d803db86721 100644
> --- a/meta/recipes-core/libxml/libxml2_2.9.14.bb
> +++ b/meta/recipes-core/libxml/libxml2_2.9.14.bb
> @@ -109,6 +109,8 @@ do_install_ptest () {
>  do_install:append:class-native () {
>         # Docs are not needed in the native case
>         rm ${D}${datadir}/gtk-doc -rf
> +
> +       create_wrapper ${D}${bindir}/xmllint XML_CATALOG_FILES=${sysconfdir}/xml/catalog
>  }
>
>  BBCLASSEXTEND = "native nativesdk"
> --
> 2.34.1
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#169715): https://lists.openembedded.org/g/openembedded-core/message/169715
> Mute This Topic: https://lists.openembedded.org/mt/93206851/3617609
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [schnitzeltony@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

On Sat, 2022-09-03 at 12:11 +0200, Andreas Müller wrote:
> Hi,
> 
> this is a major change on behaviour and causing trouble at least for
> KDE's kdoctools. Am no expert but I guess kdoctools uses custom
> catalogs. Worked around trouble in meta-qt5-extra (assume meta-kf5
> will face same) by preferring bare xmllint [1].
> Just a heads up - it is about to land in kirkstone - have no idea what
> this patch fixes.
> 
> [1] https://github.com/schnitzeltony/meta-qt5-extra/blob/master/recipes-kde/kf5/tier2/kdoctools/files/0002-Prefer-bare-xmllint.patch
> 

Thanks for the warning, I dropped it from the kirkstone pull request.

Does anyone know if that env var takes multiple paths?

If not, we probably need to adjust the wrapper to only set the envvar
if one isn't already set.

Cheers,

Richard

On 3 Sep 2022, at 13:12, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Sat, 2022-09-03 at 12:11 +0200, Andreas Müller wrote:
>> Hi,
>> 
>> this is a major change on behaviour and causing trouble at least for
>> KDE's kdoctools. Am no expert but I guess kdoctools uses custom
>> catalogs. Worked around trouble in meta-qt5-extra (assume meta-kf5
>> will face same) by preferring bare xmllint [1].
>> Just a heads up - it is about to land in kirkstone - have no idea what
>> this patch fixes.
>> 
>> [1] https://github.com/schnitzeltony/meta-qt5-extra/blob/master/recipes-kde/kf5/tier2/kdoctools/files/0002-Prefer-bare-xmllint.patch
>> 
> 
> Thanks for the warning, I dropped it from the kirkstone pull request.
> 
> Does anyone know if that env var takes multiple paths?
> 
> If not, we probably need to adjust the wrapper to only set the envvar
> if one isn't already set.

From catalog.c:

 /* the XML_CATALOG_FILES envvar is allowed to contain a
           space-separated list of entries. */

So one solution is that the wrapper should append an existing XML_CATALOG_FILES if set.  Of course, the wrapper script is generated so we’d have to write that manually.

Interestingly catalog.c has some automatic relocation support for Windows where it finds catalogues based on the location of libxml2.dll.  Using dlopen/dlinfo to do the same thing should be possible...

Ross