bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc

bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc

[Mark H Weaver]

'meson-build-system' includes 'patchelf' as an implicit input for all
packages that use it, and uses it from its 'fix-runpath' phase,
sometimes directly and sometimes via (guix build rpath).

'patchelf' is a nasty hack which seems to only work on Intel-based
systems.  It certainly doesn't work on 'mips64el-linux', and when I last
investigated it seemed hard to fix this.  As far as I can tell, it has
never built successfully on 'armhf-linux' either:

  https://hydra.gnu.org/job/gnu/master/patchelf-0.8.armhf-linux/all

I don't know about 'aarch64-linux'.

Given that 'meson-build-system' is seeing increased usage in some
important packages, e.g. 'libinput' and several GNOME packages, this is
becoming an increasingly serious problem for non-Intel platforms.

      Mark

bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> 'meson-build-system' includes 'patchelf' as an implicit input for all
> packages that use it, and uses it from its 'fix-runpath' phase,
> sometimes directly and sometimes via (guix build rpath).
>
> 'patchelf' is a nasty hack which seems to only work on Intel-based
> systems.  It certainly doesn't work on 'mips64el-linux', and when I last
> investigated it seemed hard to fix this.  As far as I can tell, it has
> never built successfully on 'armhf-linux' either:
>
>   https://hydra.gnu.org/job/gnu/master/patchelf-0.8.armhf-linux/all
>
> I don't know about 'aarch64-linux'.
>
> Given that 'meson-build-system' is seeing increased usage in some
> important packages, e.g. 'libinput' and several GNOME packages, this is
> becoming an increasingly serious problem for non-Intel platforms.

Note that this is already fixed on 'core-updates', with commits
3cc9a8a13..800564020.  See <https://bugs.gnu.org/31208>.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc

[Mark H Weaver]

Hi Marius,

Marius Bakke <mbakke@fastmail.com> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> 'meson-build-system' includes 'patchelf' as an implicit input for all
>> packages that use it, and uses it from its 'fix-runpath' phase,
>> sometimes directly and sometimes via (guix build rpath).
>>
>> 'patchelf' is a nasty hack which seems to only work on Intel-based
>> systems.  It certainly doesn't work on 'mips64el-linux', and when I last
>> investigated it seemed hard to fix this.  As far as I can tell, it has
>> never built successfully on 'armhf-linux' either:
>>
>>   https://hydra.gnu.org/job/gnu/master/patchelf-0.8.armhf-linux/all
>>
>> I don't know about 'aarch64-linux'.
>>
>> Given that 'meson-build-system' is seeing increased usage in some
>> important packages, e.g. 'libinput' and several GNOME packages, this is
>> becoming an increasingly serious problem for non-Intel platforms.
>
> Note that this is already fixed on 'core-updates', with commits
> 3cc9a8a13..800564020.  See <https://bugs.gnu.org/31208>.

I believe you're mistaken.  Those commits eliminated one of the uses of
'patchelf' in meson-build-system, but there still remains a call to
'augment-rpath' which uses patchelf, and patchelf is still added as an
implicit input.

     Thanks,
       Mark

bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> Hi Marius,
>
> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> 'meson-build-system' includes 'patchelf' as an implicit input for all
>>> packages that use it, and uses it from its 'fix-runpath' phase,
>>> sometimes directly and sometimes via (guix build rpath).
>>>
>>> 'patchelf' is a nasty hack which seems to only work on Intel-based
>>> systems.  It certainly doesn't work on 'mips64el-linux', and when I last
>>> investigated it seemed hard to fix this.  As far as I can tell, it has
>>> never built successfully on 'armhf-linux' either:
>>>
>>>   https://hydra.gnu.org/job/gnu/master/patchelf-0.8.armhf-linux/all
>>>
>>> I don't know about 'aarch64-linux'.
>>>
>>> Given that 'meson-build-system' is seeing increased usage in some
>>> important packages, e.g. 'libinput' and several GNOME packages, this is
>>> becoming an increasingly serious problem for non-Intel platforms.
>>
>> Note that this is already fixed on 'core-updates', with commits
>> 3cc9a8a13..800564020.  See <https://bugs.gnu.org/31208>.
>
> I believe you're mistaken.  Those commits eliminated one of the uses of
> 'patchelf' in meson-build-system, but there still remains a call to
> 'augment-rpath' which uses patchelf, and patchelf is still added as an
> implicit input.

Ah yes, you are right.  Apoligies for the noise.

Since I'm here, I'd like to point out that there has been some activity
upstream recently around RPATH handling:

https://github.com/mesonbuild/meson/commit/e3757e3d3cf24327c89dd3fc40f6cc933510f676

I believe this commit eliminates the need for "shrink-rpath", and
facilities are planned to also control the installed RUNPATH.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc

[Ludovic Courtès]

Hello,

Marius Bakke <mbakke@fastmail.com> skribis:

> Mark H Weaver <mhw@netris.org> writes:

[...]

>> I believe you're mistaken.  Those commits eliminated one of the uses of
>> 'patchelf' in meson-build-system, but there still remains a call to
>> 'augment-rpath' which uses patchelf, and patchelf is still added as an
>> implicit input.

Yeah, the reason is that implementing ‘augment-rpath’ is obviously
harder than implementing ‘shrink-rpath’ (the result might not fit.)

> Since I'm here, I'd like to point out that there has been some activity
> upstream recently around RPATH handling:
>
> https://github.com/mesonbuild/meson/commit/e3757e3d3cf24327c89dd3fc40f6cc933510f676
>
> I believe this commit eliminates the need for "shrink-rpath", and
> facilities are planned to also control the installed RUNPATH.

I don’t fully understand what this commit does, but it seems to be a
step in the right direction.

The “XXX” found in the RUNPATH of Epiphany
(<https://bugs.gnu.org/31970>) also seem to be there as a way to allow
RUNPATH to be adjusted upon install, meaning that we wouldn’t have
anything to do on our side.

In the meantime, I wonder if we can remove the patchelf dependency
selectively for packages where the patchelf phase isn’t necessary.
Epiphany may well fall into that category.

Thoughts?

Ludo’.

bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc

[Mark H Weaver]

severity 31971 important
thanks

Mark H Weaver <mhw@netris.org> writes:
> Given that 'meson-build-system' is seeing increased usage in some
> important packages, e.g. 'libinput' and several GNOME packages, this is
> becoming an increasingly serious problem for non-Intel platforms.

A bigger problem is 'json-glib', which uses 'meson-build-system' and
which is an input for 'gtk+'.  So, on our 'staging' branch, armhf-linux
has lost everything that depends on gtk+, including 'emacs', all of
'xfce' and 'gnome', etc.

  https://hydra.gnu.org/eval/110025?compare=110019

      Mark

bug#31971: meson-build-system uses 'patchelf' which fails on armhf-linux etc

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> 'meson-build-system' includes 'patchelf' as an implicit input for all
> packages that use it, and uses it from its 'fix-runpath' phase,
> sometimes directly and sometimes via (guix build rpath).

Since commit bf91e6835d21e3bd7b49bb85b40f61389604c6f7
‘meson-build-system’ no longer relies on PatchELF.

Closing!

Ludo’.