From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id G0bZIGhn2mE2IAAAgWs5BA (envelope-from ) for ; Sun, 09 Jan 2022 05:41:12 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id ECO+GGhn2mEVdQAAG6o9tA (envelope-from ) for ; Sun, 09 Jan 2022 05:41:12 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 97C2C14B8E for ; Sun, 9 Jan 2022 05:41:11 +0100 (CET) Received: from localhost ([::1]:44470 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n6Q10-0001mu-Rz for larch@yhetil.org; Sat, 08 Jan 2022 23:41:10 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58114) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6Q0s-0001mm-9U for bug-guix@gnu.org; Sat, 08 Jan 2022 23:41:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:56184) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n6Q0s-0004d2-0b for bug-guix@gnu.org; Sat, 08 Jan 2022 23:41:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n6Q0r-00085S-UI for bug-guix@gnu.org; Sat, 08 Jan 2022 23:41:01 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64 Resent-From: Chris Marusich Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sun, 09 Jan 2022 04:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52943 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Aiko Kyle Received: via spool by 52943-submit@debbugs.gnu.org id=B52943.164170320630993 (code B ref 52943); Sun, 09 Jan 2022 04:41:01 +0000 Received: (at 52943) by debbugs.gnu.org; 9 Jan 2022 04:40:06 +0000 Received: from localhost ([127.0.0.1]:49086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6Pzu-00083T-DF for submit@debbugs.gnu.org; Sat, 08 Jan 2022 23:40:05 -0500 Received: from mail-pj1-f53.google.com ([209.85.216.53]:43864) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6Pzn-000830-G5 for 52943@debbugs.gnu.org; Sat, 08 Jan 2022 23:40:00 -0500 Received: by mail-pj1-f53.google.com with SMTP id ie23-20020a17090b401700b001b38a5318easo3409067pjb.2 for <52943@debbugs.gnu.org>; Sat, 08 Jan 2022 20:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=ITX7M2ei4meLVzsCCIpFieXELdo+6qnQIr4vq10F3HQ=; b=mXk6a2GJNfJI/pJYPPTci81M/NdF6VDGU5ZPHnzOjR0bVAzTOTVKZsHQfFxiGpntL9 4ctu7fu2PCNK7KdxwMSKjx0Zk2sl7XQgWfnAu/WNBe314E/bvLu1plQZieT8RB5bfABV 0qC4llrBT7NXuH6a0YHQns6+wu3tNzOhm+XTPyKfrHMkGfQlFEhptSpTJ8BRPmru13m+ yg5sw/TgmAHyaFVKFjnVMUkzfJruN5ebkpRSW/F7stpaKzZq1uxxZITmWbj/mAxNvZyM zppfcBBcClo47T/31rOlZckaF6vhUYn0UEGRh034JVzEFWQp1PpQjE+xF75iMl0KwGU5 4K8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=ITX7M2ei4meLVzsCCIpFieXELdo+6qnQIr4vq10F3HQ=; b=nb5cm/HV9NrnVVgGsjUeEKj1zylVFVfmc0rdhKeykfblk0pok2kb7rHA0+IQBX7cLP WXmBTAVQGebYuuFsnrU3KgU/cwLgpIW/vDJyycB+XRXodMJP78qNYDghqTyNrXSVsZW8 fOqfZSJmj8Wxga+eB/xk1yCG2i/3E9fU0HSuGQEdEaI4Umgm7ExhNnPjvkAY4wtjnpl/ I2CYQtVNuqm1Mu3deAO8bBO4R61VQWeeyhTU1FNQ1GVMHVX+Vb45ZCFTxYZCSmgXWf/a SRs3hYCSR0KyXabk3+sLCoiOlPguowiSbycDLJcKhz1crg2yNmXxL/lCX5d5Tdkkye1b vQLw== X-Gm-Message-State: AOAM532kmnXxo6zg6LiO3esekHNhtFoYiMwA+tz1xdegSaf+i4aBfnWx zm5MtvRcL6/br2XbVmU3TUhT46jWhxA= X-Google-Smtp-Source: ABdhPJxK056KFL8/gWwIZ3hOody7NMsajEZyPpW8u7RCmhdSCOpRPApnlSdwdN2tSScw9eBrYWrIQA== X-Received: by 2002:a17:902:7105:b0:149:e08a:b31b with SMTP id a5-20020a170902710500b00149e08ab31bmr17352580pll.171.1641703188897; Sat, 08 Jan 2022 20:39:48 -0800 (PST) Received: from garuda-lan (c-24-18-44-142.hsd1.wa.comcast.net. [24.18.44.142]) by smtp.gmail.com with ESMTPSA id nl10sm4384026pjb.54.2022.01.08.20.39.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Jan 2022 20:39:48 -0800 (PST) From: Chris Marusich References: Date: Sat, 08 Jan 2022 20:39:42 -0800 In-Reply-To: (Aiko Kyle's message of "Sat, 1 Jan 2022 16:54:51 -0700") Message-ID: <87o84lcyk1.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 52943@debbugs.gnu.org Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1641703271; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=ITX7M2ei4meLVzsCCIpFieXELdo+6qnQIr4vq10F3HQ=; b=LQRC1e/4uvsZhgKaTX8PyEHsuSQA8k0eRHl1B+6q7W76rHHvp4hLhrMrx0xoQyQr/K89H+ Wr8GirXFK3JOAXTlnH5P5V13Q2q7RW3fbV2TlH2n6Y9/XoqXtKOUAq2FlqyNvjBMM4rT3c HD1MN1ooE7YcT4cuQnLouDgXok+On+gCFWat5/I8D+ttCPejhqdmiHGIm7cA6HLupuPcT2 ssVCUV8iwa38/lfuYtiE3hyURd+RRBXtdIFDaAexulg/BvcJ94dFx4wvrK0dxRKA2LZZqg hfN6kbWn0F+k1v1OmyLr1cIML94Y9gJmZR01cyZx6h0XIpa8TtyAH9MKa/6esw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641703271; a=rsa-sha256; cv=none; b=CrEjz918xan/9VyALQ1AcrqaapjTBVJaUYFLOhIoQJjou2PPJjBn7drIXmcWm+6zS4GQil iwOzxB9r9EJvi/uuAOjligy2CcJF0S5ns4SSxs69JZN0GCkYSVAXH4CFMJqoDp3Yrk0A08 63TqLOeA5kR2aBXKU6XlHhyr8JqT0WvTH7D0IMy5KwdSA8a4wQHcFq6wrqWRAUOu38P/T4 1OT3uHE4WbqzDP81misMYQafZXJeKXSi6ngsT2bKbFRryeplvb+MIyYOcuQSxtyfAojdVt kWZ/iXF6KcX4hzRH3uupw9FnlDtnThUVg2FM+3WqgvqevwpKtbRPUTIIDhISYQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=mXk6a2GJ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.61 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=mXk6a2GJ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 97C2C14B8E X-Spam-Score: -3.61 X-Migadu-Scanner: scn1.migadu.com X-TUID: 6P/wkOPMc7Nr --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Aiko Kyle writes: > On the latest master I can run 'guix pull', and the latest guix seems > to build just fine, however when I go to do 'guix system reconfigure', > building guix fails the check phase. Aiko has reported that the fix for 52908 did indeed fix the "tests/guix-system.sh" problem on aarch64-linux. This means the "service 'xorg-server' provided more than once" error has been fixed. However, fixing that issue has revealed another. Aiko said: > guix system reconfigure is still failing for me on aarch64 due to the > test 'file-needed/recursive' in tests/gremlin.scm failing. So the current status is that Aiko still can't do "guix reconfigure" on master after running "guix pull". For this reason, I have re-opened this bug and unmerged it from 52908, since it's not exactly the same issue any more. At the moment, the file-needed/recursive bug that is preventing Aiko from running "guix reconfigure" appears to be specific to aarch64-linux. The problem was reported on guix-devel here: https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00019.html Pierre Langlois did some investigation and found this information, posted in the email thread above: > I've also been trying to fix this test but without much luck. It > does look similar to this issue for ppc64 [0], where the `ldd/ld.so' > beaviour isn't the same as what the gremlin guile module does. However > the patch proposed there isn't fixing the issue for me either on > aarch64. >=20 > [0]: https://issues.guix.gnu.org/52940, >=20 > Maybe we can compare notes and a solution will come up :-). So the test > fails because 'truth', the result from `ldd', has ld-linux-aarch64.so > listed while 'needed', from the gremlin guile module doesn't: >=20 > --8<---------------cut here---------------start------------->8--- > (truth ;; result from `ldd libguile.so' > ("/gnu/store/...-gcc-10.3.0-lib/lib/libgcc_s.so.1" > "/gnu/store/...-glibc-2.33/lib/ld-linux-aarch64.so.1" ;; This isn't > ;; in gremlins > "/gnu/store/...-glibc-2.33/lib/libc.so.6" > "/gnu/store/...-glibc-2.33/lib/libcrypt.so.1" > "/gnu/store/...-glibc-2.33/lib/libdl.so.2" > "/gnu/store/...-glibc-2.33/lib/libm.so.6" > "/gnu/store/...-glibc-2.33/lib/libpthread.so.0" > "/gnu/store/...-guile-3.0.7/lib/libguile-3.0.so.1" > "/gnu/store/...-libffi-3.3/lib/libffi.so.7" > "/gnu/store/...-libgc-8.0.4/lib/libgc.so.1" > "/gnu/store/...-libunistring-0.9.10/lib/libunistring.so.2")) >=20 > (needed ;; result from gremlin > ("/gnu/store/...-gcc-10.3.0-lib/lib/libgcc_s.so.1" > "/gnu/store/...-glibc-2.33/lib/libc.so.6" > "/gnu/store/...-glibc-2.33/lib/libcrypt.so.1" > "/gnu/store/...-glibc-2.33/lib/libdl.so.2" > "/gnu/store/...-glibc-2.33/lib/libm.so.6" > "/gnu/store/...-glibc-2.33/lib/libpthread.so.0" > "/gnu/store/...-guile-3.0.7/lib/libguile-3.0.so.1" > "/gnu/store/...-libffi-3.3/lib/libffi.so.7" > "/gnu/store/...-libgc-8.0.4/lib/libgc.so.1" > "/gnu/store/...-libunistring-0.9.10/lib/libunistring.so.2")) > --8<---------------cut here---------------end--------------->8--- >=20 > Digging a bit more I started comparing x86_64 and aarch64 binaries and > noticed that libguile.so didn't have the same dynamic section: >=20 > --8<---------------cut here---------------start------------->8--- > # On aarch64: > $ objdump -x=20 > /gnu/store/pqw0c33k2h8n2snpchnyvx7w617kk31s-guile-3.0.7/lib/libguile-3.0.= so.1.4.0 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > /gnu/store/pqw0c33k2h8n2snpchnyvx7w617kk31s-guile-3.0.7/lib/libguile-3.0.= so.1.4.0: > file format elf64-littleaarch64=20=20=20=20 > ... > Dynamic Section:=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > NEEDED libgc.so.1=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > NEEDED libpthread.so.0=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > NEEDED libffi.so.7=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > NEEDED libunistring.so.2=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > NEEDED libcrypt.so.1=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > NEEDED libdl.so.2=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > NEEDED libm.so.6=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > NEEDED libgcc_s.so.1=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > NEEDED libc.so.6=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20 > SONAME libguile-3.0.so.1=20=20=20=20 > ... >=20 > # On x86_64: > $ objdump -x=20 > /gnu/store/3h3jn0745ngd87zp83k5smwhykxvdfgf-guile-3.0.7/lib/libguile-3.0.= so.1.4.0 >=20 > /gnu/store/3h3jn0745ngd87zp83k5smwhykxvdfgf-guile-3.0.7/lib/libguile-3.0.= so.1.4.0: > file format elf64-x86-64 > ... > Dynamic Section: > NEEDED libgc.so.1 > NEEDED libpthread.so.0 > NEEDED libffi.so.7 > NEEDED libunistring.so.2 > NEEDED libcrypt.so.1 > NEEDED libdl.so.2 > NEEDED libm.so.6 > NEEDED libgcc_s.so.1 > NEEDED libc.so.6 > NEEDED ld-linux-x86-64.so.2 # ld-linux-.so is here > SONAME libguile-3.0.so.1 > ... > --8<---------------cut here---------------end--------------->8--- >=20 > On aarch64, ld-linux- is missing. I'm not sure if this is an > issue with our aarch64 port or if that's OK. It's interesting though > that if you run `ldd' on libguile on aarch64, the dynamic linker is > added to the list, even though it's not in the dynamic section: >=20 > --8<---------------cut here---------------start------------->8--- > # On aarch64 > $ ldd=20 > /gnu/store/pqw0c33k2h8n2snpchnyvx7w617kk31s-guile-3.0.7/lib/libguile-3.0.= so.1.4.0 > linux-vdso.so.1 (0x0000ffff96fab000) > libgc.so.1 =3D>=20 > /gnu/store/1gkpbfxjx2sbchjhf19yjm4a8vkir0nm-libgc-8.0.4/lib/libgc.so.1=20 > (0x0000ffff96d88000) > libpthread.so.0 =3D>=20 > /gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libpthread.so.= 0=20 > (0x0000ffff96d59000) > libffi.so.7 =3D>=20 > /gnu/store/hjirgm7pwmc2biqz6d0fc1ajr3ha4v14-libffi-3.3/lib/libffi.so.7=20 > (0x0000ffff96d40000) > libunistring.so.2 =3D>=20 > /gnu/store/4k552fq1p6q73mr9ww7g5y3m77p7cfbm-libunistring-0.9.10/lib/libun= istring.so.2 > (0x0000ffff96bb4000) > libcrypt.so.1 =3D>=20 > /gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libcrypt.so.1= =20 > (0x0000ffff96b6d000) > libdl.so.2 =3D>=20 > /gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libdl.so.2=20 > (0x0000ffff96b59000) > libm.so.6 =3D>=20 > /gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libm.so.6=20 > (0x0000ffff96ab0000) > libgcc_s.so.1 =3D>=20 > /gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib/libgcc_s.s= o.1=20 > (0x0000ffff96a8b000) > libc.so.6 =3D>=20 > /gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libc.so.6=20 > (0x0000ffff96917000) >=20=20=20=20=20=20=20=20=20 > /gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/ld-linux-aarch= 64.so.1 > (0x0000ffff96f79000) > # ^ > --8<---------------cut here---------------end--------------->8--- >=20 > We could adapt the test to add the dynamic linker, emulating `ldd', but > I'm curious if anybody deeply familiar with ELF and dynamic linking > might have an idea what's going on. To summarize, this seems to be the problem: On aarch64-linux, when an ELF file's dynamic section does not contain a NEEDED entry for ld-linux-aarch64.so.1, file-needed/recursive dutifully omits that entry, but ldd prints it (even though it is actually missing from the file's dynamic section). This causes the file-needed/recursive test in tests/gremlin.scm to fail because the set of entries returned by file-needed/recursive differs from the set of entries returned by ldd. Although this may sound similar to 52940, it is different. Bug 52940 was an issue where, when an ELF file's dynamic section contains two entries in RUNPATH that are different strings but refer to the same directory (which does happen on powerpc64le-linux), it causes file-needed/recursive to include in its result two entries that are different strings but refer to the same file. We decided that such redundant entries are probably benign, so we resolved 52940 by changing the test to compare entries by file equality, rather than string equality. However, this is not the same issue as described by Aiko and Pierre above, so it makes sense that the fix for 52940 did not fix the test for aarch64-linux. So, the separate aarch64-linux problem with file-needed/recursive persists. For comparison, on powerpc64le-linux, when an ELF file's dynamic section does not contain a NEEDED entry for "ld64.so.2" (I believe this is the powerpc64le-linux equivalent of ld-linux-aarch64.so.1), both ldd and file-needed/recursive include ld64.so.2, despite the fact that there is no actual NEEDED entry for it in the ELF file. Here is what I see on a powerpc64le-linux system: =2D-8<---------------cut here---------------start------------->8--- marusich@suzaku ~/guix-master [env]$ type -P guile /gnu/store/qr79b2m6cfdj8ar7g0psqg4hglm6djfm-profile/bin/guile marusich@suzaku ~/guix-master [env]$ type -P ldd /gnu/store/qr79b2m6cfdj8ar7g0psqg4hglm6djfm-profile/bin/ldd marusich@suzaku ~/guix-master [env]$ ldd /gnu/store/qr79b2m6cfdj8ar7g0psqg4= hglm6djfm-profile/bin/guile linux-vdso64.so.1 (0x00007fff89220000) libguile-3.0.so.1 =3D> /gnu/store/47s31zvkhk2ixqn0z7gq6hpz7j7cn9dl-= guile-3.0.7/lib/libguile-3.0.so.1 (0x00007fff89050000) libgc.so.1 =3D> /gnu/store/csqz3w2axyci2qm79xsj11cpfxqh7zb1-libgc-8= .0.4/lib/libgc.so.1 (0x00007fff88fb0000) libpthread.so.0 =3D> /gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-gl= ibc-2.33/lib/libpthread.so.0 (0x00007fff88f60000) libffi.so.7 =3D> /gnu/store/kmgva3hbpk1bv0gvx5s4w01n0fdvd2l9-libffi= -3.3/lib/../lib/libffi.so.7 (0x00007fff88f30000) libunistring.so.2 =3D> /gnu/store/zf87w2xccli6yvxpplfwd82gcgm6jyrd-= libunistring-0.9.10/lib/libunistring.so.2 (0x00007fff88d80000) libcrypt.so.1 =3D> /gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glib= c-2.33/lib/libcrypt.so.1 (0x00007fff88d30000) libdl.so.2 =3D> /gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2= .33/lib/libdl.so.2 (0x00007fff88d00000) libm.so.6 =3D> /gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.= 33/lib/libm.so.6 (0x00007fff88bb0000) libgcc_s.so.1 =3D> /gnu/store/l0hnwrv8ma03shjg84a03s05wmj7a0sk-gcc-= 10.3.0-lib/lib/libgcc_s.so.1 (0x00007fff88b70000) libc.so.6 =3D> /gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.= 33/lib/libc.so.6 (0x00007fff88950000) /gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/ld64.so.= 2 (0x00007fff89240000) marusich@suzaku ~/guix-master [env]$ readelf -d /gnu/store/qr79b2m6cfdj8ar7= g0psqg4hglm6djfm-profile/bin/guile Dynamic section at offset 0xfc60 contains 37 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libguile-3.0.so.1] 0x0000000000000001 (NEEDED) Shared library: [libgc.so.1] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libffi.so.7] 0x0000000000000001 (NEEDED) Shared library: [libunistring.so.2] 0x0000000000000001 (NEEDED) Shared library: [libcrypt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000001d (RUNPATH) Library runpath: [/gnu/store/47s31= zvkhk2ixqn0z7gq6hpz7j7cn9dl-guile-3.0.7/lib:/gnu/store/csqz3w2axyci2qm79xsj= 11cpfxqh7zb1-libgc-8.0.4/lib:/gnu/store/kmgva3hbpk1bv0gvx5s4w01n0fdvd2l9-li= bffi-3.3/lib/../lib:/gnu/store/zf87w2xccli6yvxpplfwd82gcgm6jyrd-libunistrin= g-0.9.10/lib:/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib:/gn= u/store/l0hnwrv8ma03shjg84a03s05wmj7a0sk-gcc-10.3.0-lib/lib:/gnu/store/3jr8= 4ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/../lib:/gnu/store/l0hnwrv8ma03s= hjg84a03s05wmj7a0sk-gcc-10.3.0-lib/lib/gcc/powerpc64le-unknown-linux-gnu/10= .3.0/../../../../lib] 0x000000000000000c (INIT) 0x100009e0 0x000000000000000d (FINI) 0x10000f30 0x0000000000000019 (INIT_ARRAY) 0x1001fc50 0x000000000000001b (INIT_ARRAYSZ) 8 (bytes) 0x000000000000001a (FINI_ARRAY) 0x1001fc58 0x000000000000001c (FINI_ARRAYSZ) 8 (bytes) 0x0000000000000004 (HASH) 0x100002a0 0x000000006ffffef5 (GNU_HASH) 0x100002f8 0x0000000000000005 (STRTAB) 0x100004a8 0x0000000000000006 (SYMTAB) 0x10000328 0x000000000000000a (STRSZ) 894 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000015 (DEBUG) 0x0 0x0000000000000003 (PLTGOT) 0x10020000 0x0000000000000002 (PLTRELSZ) 216 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x100008e8 0x0000000070000000 (PPC64_GLINK) 0x10000eec 0x0000000070000003 (PPC64_OPT) 0x0 0x0000000000000007 (RELA) 0x10000888 0x0000000000000008 (RELASZ) 96 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x10000848 0x000000006fffffff (VERNEEDNUM) 2 0x000000006ffffff0 (VERSYM) 0x10000826 0x0000000000000000 (NULL) 0x0 marusich@suzaku ~/guix-master [env]$ ./pre-inst-env guix repl GNU Guile 3.0.7 Copyright (C) 1995-2021 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guix-user)> ,use (guix build gremlin) scheme@(guix-user)> ,pp (file-needed/recursive "/gnu/store/qr79b2m6cfdj8ar7= g0psqg4hglm6djfm-profile/bin/guile") $1 =3D ("/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libc.so= .6" "/gnu/store/l0hnwrv8ma03shjg84a03s05wmj7a0sk-gcc-10.3.0-lib/lib/libgcc_s.s= o.1" "/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libm.so.6" "/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libdl.so.2" "/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libcrypt.so.1" "/gnu/store/zf87w2xccli6yvxpplfwd82gcgm6jyrd-libunistring-0.9.10/lib/libun= istring.so.2" "/gnu/store/kmgva3hbpk1bv0gvx5s4w01n0fdvd2l9-libffi-3.3/lib/../lib/libffi.= so.7" "/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libpthread.so.= 0" "/gnu/store/csqz3w2axyci2qm79xsj11cpfxqh7zb1-libgc-8.0.4/lib/libgc.so.1" "/gnu/store/47s31zvkhk2ixqn0z7gq6hpz7j7cn9dl-guile-3.0.7/lib/libguile-3.0.= so.1" "/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/ld64.so.2" "/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/../lib/libc.so= .6") $2 =3D ("ld64.so.2") scheme@(guix-user)> =2D-8<---------------cut here---------------end--------------->8--- I don't know if it's related, but I just noticed this: it's a little strange that in the above output (for powerpc64le-linux), ld64.so.2 is included in the second value ($2). This is supposedly the list of .so file names that could not be found. It's strange that ld64.so.2 shows up in $2 because it seems to contradict the fact that it is included in $1, which is the list of files that were found successfully. Since Pierre shared information about the libguile shared object specifically, I'll do the same here. On powerpc64le-linux, the "ld64.so.2" entry is present in the dynamic section of the /gnu/store/47s31zvkhk2ixqn0z7gq6hpz7j7cn9dl-guile-3.0.7/lib/libguile-3.0.so= .1 ELF file: =2D-8<---------------cut here---------------start------------->8--- marusich@suzaku ~/guix-master [env]$ readelf -d /gnu/store/47s31zvkhk2ixqn0= z7gq6hpz7j7cn9dl-guile-3.0.7/lib/libguile-3.0.so.1| grep -e NEEDED -e RUNPA= TH 0x0000000000000001 (NEEDED) Shared library: [libgc.so.1] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libffi.so.7] 0x0000000000000001 (NEEDED) Shared library: [libunistring.so.2] 0x0000000000000001 (NEEDED) Shared library: [libcrypt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld64.so.2] 0x000000000000001d (RUNPATH) Library runpath: [/gnu/store/csqz3= w2axyci2qm79xsj11cpfxqh7zb1-libgc-8.0.4/lib:/gnu/store/kmgva3hbpk1bv0gvx5s4= w01n0fdvd2l9-libffi-3.3/lib/../lib:/gnu/store/zf87w2xccli6yvxpplfwd82gcgm6j= yrd-libunistr ing-0.9.10/lib:/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib:/= gnu/store/l0hnwrv8ma03shjg84a03s05wmj7a0sk-gcc-10.3.0-lib/lib:/gnu/store/3j= r84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/../lib:/gnu/store/l0hnwrv8ma0= 3shjg84a03s05 wmj7a0sk-gcc-10.3.0-lib/lib/gcc/powerpc64le-unknown-linux-gnu/10.3.0/../../= ../../lib] =2D-8<---------------cut here---------------end--------------->8--- Maybe this information can help somehow. It seems fishy that on aarch64-linux, there is no NEEDED entry for ld-linux-aarch64.so.1 in the ELF files under consideration. As shown above, a similar entry DOES exist on both x86_64-linux and powerpc64le-linux. For this reason, it seems plausible that maybe the missing NEEDED entry is bad. However, I don't really know enough to say whether it's indicative of a problem with our aarch64-linux port. Is there an aarch64-linux or ELF expert in the room who can help? :-) It also seems fishy that, on powerpc64le-linux, file-needed/recursive apparently resolves ld64.so.2 successfully, even though it simultaneously includes it in the "failed to resolve" list. Confusing as that is to me, I don't know if that's really related to the aarch64-linux issue. More investigation is needed... =2D-=20 Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=3D106836 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJJBAEBCAAzFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAmHaZw4VHGNtbWFydXNp Y2hAZ21haWwuY29tAAoJEN1AmhXYIkadp/8P/j8kro3YsstMpEFJu7Dv/Rbpumbq aaxTxCcUFns9SrL+ixd+nSbJs1Rb1AGAX4VKrFxOOsSyL/tktOZyKBTc+QNGHIaA wOH4UVY0Oeb9OEoqvO8lGUqEjwVdTZwwL8fuNPAk2MIBiFRTDtUl/cQDeH9241H5 UHR0NmvNETxAj2jCQUmt7KNSu3ZPeCHlXH3BwQKRKn5K1xQvjROI5OWlmhjlr5Wk 3F8cC5nR0Q6JN1/ZKjbu+HFEmrUT+865RtMK5vTXwnip6/g86Hpq7T0EBLXDN0CV 2irJplHKuR95f71w6B3K5rbvfz4ERJ5Hss7q0xIkXGnwOdL6NKJqI9y+na33uWN/ RqI4VCT7Y4XFFOVW8gp0bcpnsiLMyxy7soAbx2AY8+iuP992RWjHxuENDI6E+69h cUYQD40/7jSmfWweCgTFWdTbo2pDg96vPtDmWdLYo5Qn+Bs+jx5hMDdS/myY/C5L +4wWGiAVzmTbybbgiqlnpH1mi992kzqRiI02vTV/CXthOXL9X1KC9zz/LO0brS85 lYpSEavC6NV24ijJzU/xOQs++J/Ace+G9Z3Cuiut3pizvy77F+X9dbNhDZtawmQt qQYl38hsj/rT0ru+s8PsA0grPmk0TlX1WmOvIU83gnqmj78E3fk2WCHU4BvKryMM hpuzmb90D0ACj1ux =AYD0 -----END PGP SIGNATURE----- --=-=-=--