ludo@gnu.org (Ludovic Courtès) writes: > Hello, > > Mark H Weaver skribis: > >> Marius Bakke writes: > > [...] > >>> I'm sorry, I forgot to address your actual concerns. The (buggy) >>> workaround was put in place and discussed in >>> . The meat of it can be found in (guix >>> build-system meson): >>> >>> ;; XXX PatchELF fails to build on armhf, so we skip >>> ;; the 'fix-runpath' phase there for now. It is used >>> ;; to avoid superfluous entries in RUNPATH as described >>> ;; in , so armhf may now >>> ;; have different runtime dependencies from other arches. >> >> Thanks for this, but I'd still like to know the answer to my questions: >> "What does the [fix-runpath] phase accomplish, and how will armhf users >> be disadvantaged by the removal of that phase?" > > As discussed in and > , Meson does not (or did not) adjust > RUNPATHs upon installation (contrary to what Libtool does, for > instance.) > > Consequently, the RUNPATH is left with /tmp/guix-build-… entries, which > is not great but okay, but more importantly if usually lacks OUTPUT/lib > as well. I haven't seen /tmp in RUNPATH during my testing, which would be a *huge* security problem. The only consequence I've noticed from dropping 'fix-runpath' is that it sometimes contain entries that are not in NEEDED (but often required for a "neighbour" library, so no big deal). > However, the commit Marius referred to¹ as well as what you reported for > Epiphany in #31974 suggest that things are improving in Meson proper, > and that we might be able to remove that ‘fix-runpath’ phase altogether > soon. > > I think we should simply try building things without ‘fix-runpath’ and > see if ‘validate-runpath’ reports anything. > > Thoughts? I'm in favor of removing it on all architectures and see how it fares. I suspect the main reason for adding it was that /lib was often lacking, which is mitigated by 09a45ffb146fda75b87f89c729c31d1da5bf93da. I'll prepare patches for this for the next staging round.