From mboxrd@z Thu Jan 1 00:00:00 1970 From: Caleb Ristvedt Subject: can't get past commencement in test-env Date: Tue, 13 Aug 2019 23:21:21 -0500 Message-ID: <87ef1o1iny.fsf@cune.org> 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]:39408) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hxkmx-0003pK-FH for guix-devel@gnu.org; Wed, 14 Aug 2019 00:21:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hxkmv-0003LQ-TG for guix-devel@gnu.org; Wed, 14 Aug 2019 00:21:30 -0400 Received: from mail-ot1-x32c.google.com ([2607:f8b0:4864:20::32c]:46265) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hxkmv-0003J7-F9 for guix-devel@gnu.org; Wed, 14 Aug 2019 00:21:29 -0400 Received: by mail-ot1-x32c.google.com with SMTP id z17so60867843otk.13 for ; Tue, 13 Aug 2019 21:21:29 -0700 (PDT) Received: from GuixPotato ([208.89.170.37]) by smtp.gmail.com with ESMTPSA id j25sm155636657ioj.67.2019.08.13.21.21.26 for (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 13 Aug 2019 21:21:27 -0700 (PDT) List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org gcc-boot0 in (gnu packages commencement) compiles subtly differently when built in a chroot (for example, by an installed daemon) compared to when built without root privileges (for example, in test-env). Specifically, the presence of this line in the build log: ../../gcc-5.5.0/gcc/genmultilib: ./tmpmultilib: /bin/sh: bad interpreter: N= o such file or directory This doesn't get caught by the patch-shebangs or patch-generated-shebangs phases because tmpmultilib is both generated and immediately executed by genmultilib in order to, I kid you not, implement recursion in a portable manner by having tmpmultilib run itself. Somehow this works out in the chroot case despite it failing to run, but in the non-chroot case /bin/sh actually exists, at least on Guix System. This ultimately causes two different compilers to be created in the two cases. In the chroot case, 'g++ -print-multi-os-directory' simply gives .; while in the non-chroot case, it gives ../lib64 This means that when the bootstrap continues, libstdc++ is built with its outputs going to different locations (lib/ or lib64/) depending on which of the two compilers builds it. gcc-final assumes it will be in lib, and so it can't find it if libstdc++ was built with a gcc-boot0 built without a chroot. I don't know much about multilib stuff, but it would seem that the "correct" output from gcc's perspective would be one in which its contemplation of the matter isn't interrupted by a "bad interpreter" error. But that's also the opposite of the assumptions we currently make, and changing it would require both rebuilding the world and modifying several packages. At the same time, I'd like to be able to test building derivations in test-env without needing to run it as root (and modifying test-env slightly to remove the --disable-chroot, and choosing between running all those builders as root (yikes) or risking interfering with my installed daemon by using the same build group). I'd also appreciate it if others could test building packages in test-env easily, as it catches an entire class of errors that usually isn't caught otherwise (typically errors caused by assumptions about where the store is). The same issues that plague test-env will also occur in an unprivileged install. What is The Right Thing=E2=84=A2 to do here? - reepca