GNU bug report logs - #38055
patchelf: Assertion failed when setting interpreter

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Ivan Vilata i Balaguer <ivan <at> selidor.net>
Cc: Efraim Flashner <efraim <at> flashner.co.il>, 38055 <at> debbugs.gnu.org
Subject: bug#38055: patchelf: Assertion failed when setting interpreter
Date: Thu, 07 Nov 2019 21:55:03 +0100

Bona nit!

Ivan Vilata i Balaguer <ivan <at> selidor.net> skribis:

> Yeah, as I mentioned in the original mail that particular problem does indeed
> seem to be fixed in 0.10.  However when I try to build that source with `guix
> build patchelf --with-source=…`, tests fail.
>
> If I run `guix environment -C --pure patchelf` then unpack and build the
> source, the only test that actually fails is `no-rpath.sh`.  If I run `sh -x
> no-rpath.sh` I get this:
>
> ```
> ++ basename no-rpath.sh .sh
> + SCRATCH=scratch/no-rpath
> + rm -rf scratch/no-rpath
> + mkdir -p scratch/no-rpath
> + cp no-rpath scratch/no-rpath/
> ++ ../src/patchelf --print-rpath scratch/no-rpath/no-rpath
> + oldRPath=/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib:/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib:/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/../../..:/gnu/store/dcrwf5irwh39knld1wim1qkny659af9g-profile/lib
> + test -n /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib:/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib:/gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.4.0/../../..:/gnu/store/dcrwf5irwh39knld1wim1qkny659af9g-profile/lib
> + exit 1
> ```
>
> To succeed, the output of `…/patchelf --print-rpath …/no-rpath`
> (i.e. `oldRPath`) should be empty.  I'm not that familiar with Guix's GNU
> build system, but is that at all possible under Guix?  I mean, maybe the test
> is pointless or must be altered in some Guix-specific way for the `no-rpath`
> binary not to have an rpath.

Guix’ ‘gcc’ automatically adds RUNPATH entries to glibc/lib and
gcc:lib/lib:

--8<---------------cut here---------------start------------->8---
$ gcc -dumpspecs |grep -e -rpath
%{!mandroid|tno-android-ld:-L/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib %{!static:-rpath=/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib %{!static-libgcc:-rpath=/gnu/store/347y0zr1a9s2f5pkcncgi3gd0r33qq81-gcc-9.2.0-lib/lib -lgcc_s}} %{pthread:-lpthread} %{shared:-lc}    %{!shared:%{profile:-lc_p}%{!profile:-lc}};:%{shared:-lc}    %{!shared:%{profile:-lc_p}%{!profile:-lc}} %{!static: -ldl}}
--8<---------------cut here---------------end--------------->8---

The code that modifies GCC to do that is in (gnu packages gcc).

Thus, RUNPATH is never empty, and the test above is bound to fail.

Two possibilities: change the test to ensure that ‘--print-rpath’
returns precisely libc/lib:gcc/lib, or, if that turns out to be tricky,
skip the test (in both cases, add a comment linking to this discussion
for future reference.)

How does that sound?

Thank you!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.