GNU bug report logs -
#31971
meson-build-system uses 'patchelf' which fails on armhf-linux etc
Previous Next
Reported by: Mark H Weaver <mhw <at> netris.org>
Date: Mon, 25 Jun 2018 22:53:02 UTC
Severity: important
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31971 in the body.
You can then email your comments to 31971 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#31971
; Package
guix
.
(Mon, 25 Jun 2018 22:53:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Mark H Weaver <mhw <at> netris.org>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Mon, 25 Jun 2018 22:53:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
'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
Information forwarded
to
bug-guix <at> gnu.org
:
bug#31971
; Package
guix
.
(Mon, 25 Jun 2018 23:35:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 31971 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Mark H Weaver <mhw <at> 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>.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#31971
; Package
guix
.
(Tue, 26 Jun 2018 09:09:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 31971 <at> debbugs.gnu.org (full text, mbox):
Hi Marius,
Marius Bakke <mbakke <at> fastmail.com> writes:
> Mark H Weaver <mhw <at> 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
Information forwarded
to
bug-guix <at> gnu.org
:
bug#31971
; Package
guix
.
(Tue, 26 Jun 2018 09:50:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 31971 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Mark H Weaver <mhw <at> netris.org> writes:
> Hi Marius,
>
> Marius Bakke <mbakke <at> fastmail.com> writes:
>
>> Mark H Weaver <mhw <at> 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.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#31971
; Package
guix
.
(Wed, 27 Jun 2018 20:14:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 31971 <at> debbugs.gnu.org (full text, mbox):
Hello,
Marius Bakke <mbakke <at> fastmail.com> skribis:
> Mark H Weaver <mhw <at> 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’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#31971
; Package
guix
.
(Fri, 29 Jun 2018 19:00:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 31971 <at> debbugs.gnu.org (full text, mbox):
severity 31971 important
thanks
Mark H Weaver <mhw <at> 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
Severity set to 'important' from 'normal'
Request was from
Mark H Weaver <mhw <at> netris.org>
to
control <at> debbugs.gnu.org
.
(Fri, 29 Jun 2018 19:00:03 GMT)
Full text and
rfc822 format available.
Reply sent
to
Ludovic Courtès <ludo <at> gnu.org>
:
You have taken responsibility.
(Wed, 09 Jan 2019 20:42:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Mark H Weaver <mhw <at> netris.org>
:
bug acknowledged by developer.
(Wed, 09 Jan 2019 20:42:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 31971-done <at> debbugs.gnu.org (full text, mbox):
Mark H Weaver <mhw <at> 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’.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 07 Feb 2019 12:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 71 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.