From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#38055: patchelf: Assertion failed when setting interpreter Date: Thu, 07 Nov 2019 21:55:03 +0100 Message-ID: <87zhh7mmoo.fsf@gnu.org> References: <20191104045614.GI17621@sax.terramar.selidor.net> <87muda1kfs.fsf@gnu.org> <20191105161822.GG14453@E5400> <20191106214221.GL17621@sax.terramar.selidor.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:55537) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSop2-00012j-SE for bug-guix@gnu.org; Thu, 07 Nov 2019 15:56:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iSop1-00057b-NJ for bug-guix@gnu.org; Thu, 07 Nov 2019 15:56:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:35161) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iSop0-00056z-Em for bug-guix@gnu.org; Thu, 07 Nov 2019 15:56:03 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iSop0-0000YP-BB for bug-guix@gnu.org; Thu, 07 Nov 2019 15:56:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <20191106214221.GL17621@sax.terramar.selidor.net> (Ivan Vilata i. Balaguer's message of "Wed, 6 Nov 2019 16:42:21 -0500") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ivan Vilata i Balaguer Cc: 38055@debbugs.gnu.org Bona nit! Ivan Vilata i Balaguer skribis: > Yeah, as I mentioned in the original mail that particular problem does in= deed > seem to be fixed in 0.10. However when I try to build that source with `= guix > build patchelf --with-source=3D=E2=80=A6`, 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=3Dscratch/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=3D/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib:/= gnu/store/2plcy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib:/gnu/store/2pl= cy91lypnbbysb18ymnhaw3zwk8pg1-gcc-7.4.0-lib/lib/gcc/x86_64-unknown-linux-gn= u/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/2plcy9= 1lypnbbysb18ymnhaw3zwk8pg1-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 `=E2=80=A6/patchelf --print-rpath =E2=80=A6/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-rpa= th` > binary not to have an rpath. Guix=E2=80=99 =E2=80=98gcc=E2=80=99 automatically adds RUNPATH entries to g= libc/lib and gcc:lib/lib: --8<---------------cut here---------------start------------->8--- $ gcc -dumpspecs |grep -e -rpath %{!mandroid|tno-android-ld:-L/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-gl= ibc-2.29/lib %{!static:-rpath=3D/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj= -glibc-2.29/lib %{!static-libgcc:-rpath=3D/gnu/store/347y0zr1a9s2f5pkcncgi3= gd0r33qq81-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 =E2=80=98--print-rpath=E2= =80=99 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=E2=80=99.