Mark H Weaver writes: > Hi Marius, > > Marius Bakke writes: > >> Mark H Weaver 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 . > > 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.