Subject: Re: bug#36535: [PATCH] gnu: gobject-introspection: Update absolute-shlib-path.patch.

From: Marius Bakke <[email-masked]>
Date: Mon, 08 Jul 2019 18:29:56 +0200

Christopher Baines <[email-masked]> writes:

> Marius Bakke <[email-masked]> writes:
>
>> Hi Chris,
>>
>> Christopher Baines <[email-masked]> writes:
>>
>>> Christopher Baines <[email-masked]> writes:
>>>
>>>> Incorporate some changes from nixpkgs to the gobject-introspection package
>>>> patches.  This is motivated by looking at issues with libsoup and lollypop.
>>>> This changes means that the share/gir-1.0/Soup-2.4.gir file within libsoup
>>>> references libsoup-2.4.so.1 with an absolute filename, whereas previously, the
>>>> filename wasn't absolute.
>>>>
>>>> * gnu/packages/patches/gobject-introspection-absolute-shlib-path.patch:
>>>> Incorporate changes from nixpkgs.
>>>> ---
>>>>  ...ct-introspection-absolute-shlib-path.patch | 141 +++++++++++++++++-
>>>>  1 file changed, 137 insertions(+), 4 deletions(-)
>>>>
>>>
>>> I've pushed this as [1] to core-updates now, as I wanted to get it in
>>> before the freeze.
>>
>> Thank you for addressing this.  IIUC previously lollypop failed to
>> retain a reference to libsoup-2.4.so.1, whereas with this patch it does?
>
> Not quite... I think lollypop was reading the typelib in libsoup, but
> the shared library was just referenced by filename, not the absolute
> filename, and I think this was causing issues when trying to use libsoup
> from lollypop.

I see, thanks for explaining.  In Guix, we usually resolve these
situations by native-search-paths, do you know if gobject-introspection
supports looking up the 'share/gir-1.0' directory from an environment
variable (similar to how GI_TYPELIB_PATH works today)?  However...

>
> On master:
>
> grep shared-library /gnu/store/bafaiiblr2vmmf1zvidkw1137ndqnqg2-libsoup-2.66.2/share/gir-1.0/Soup-2.4.gir
>              shared-library="libsoup-2.4.so.1"
>
> On core-updates:
>
> grep shared-library /gnu/store/b1ykh6xj11v7zav4r68v8qflk31cnddm-libsoup-2.66.2/share/gir-1.0/Soup-2.4.gir
>              shared-library="/gnu/store/b1ykh6xj11v7zav4r68v8qflk31cnddm-libsoup-2.66.2/lib/libsoup-2.4.so.1"

...this is even better, so I am mostly just curious :-)

>> A few comments about the patch:
>>
>>> diff --git a/gnu/packages/patches/gobject-introspection-absolute-shlib-path.patch b/gnu/packages/patches/gobject-introspection-absolute-shlib-path.patch
>>> index d00cc5a420..3c0bb1c6cf 100644
>>> --- a/gnu/packages/patches/gobject-introspection-absolute-shlib-path.patch
>>> +++ b/gnu/packages/patches/gobject-introspection-absolute-shlib-path.patch
>>> @@ -2,10 +2,131 @@
>>>  # add the full path.
>>>  #
>>>  # This patch was provided by Luca Bruno <[email-masked]>  for
>>> -# 'gobject-introspection' 1.40.0 in Nix.
>>> ---- ./giscanner/utils.py.orig	2014-08-14 22:05:05.055334080 +0200
>>> -+++ ./giscanner/utils.py	2014-08-14 22:05:24.687497334 +0200
>>> -@@ -110,17 +110,11 @@
>>> +# 'gobject-introspection' 1.40.0 in Nix.
>>> +#
>>> +# It has since been updated to work with newer versions of
>>> +# gobject-introspection.
>>> +--- a/giscanner/scannermain.py
>>> ++++ b/giscanner/scannermain.py
>>> +@@ -95,6 +95,39 @@ def get_windows_option_group(parser):
>>> +     return group
>>> +
>>> +
>>> ++def _get_default_fallback_libpath():
>>> ++    # Newer multiple-output-optimized stdenv has an environment variable
>>> ++    # $outputLib which in turn specifies another variable which then is used as
>>> ++    # the destination for the library contents (${!outputLib}/lib).
>>> ++    store_path = os.environ.get(os.environ.get("outputLib")) if "outputLib" in os.environ else None
>>> ++    if store_path is None:
>>> ++        outputs = os.environ.get("outputs", "out").split()
>>
>> gnu-build-system does not currently export an "outputs" variable.
>> Perhaps it should?
>
> Ah, I didn't realise this part of the patch was as Nix specific as it
> is...
>
> At least for the change I was trying to affect, this seems to be
> probably redundant, or somehow doing the job. Maybe this part of the
> patch relating to the fallback_libpath should be removed.

I'd keep the "$outputs" logic, it sounds like a useful and easy change
to do in gnu-build-system, although maybe not for this 'core-updates'
round.  We can use it in package recipes for fun and profit meanwhile.

However I doubt we'll ever use "outputLib", so it would be good to
remove that.

If you are updating the patch, could you also add a link to the upstream
patch, as well as one to this discussion?

Thank you!