From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Cross-compilation, Guix "system", and GNU "triplet" Date: Sat, 25 Nov 2017 17:42:22 +0100 Message-ID: <87a7zaxqc1.fsf@gnu.org> References: <87shd4sduo.fsf@gmail.com> <871sknbxb4.fsf@gnu.org> <878teuvgpi.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIdXC-0002i6-3N for guix-devel@gnu.org; Sat, 25 Nov 2017 11:42:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIdXA-0000MN-QW for guix-devel@gnu.org; Sat, 25 Nov 2017 11:42:30 -0500 Received: from hera.aquilenet.fr ([2a01:474::1]:57597) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eIdXA-0000L8-EV for guix-devel@gnu.org; Sat, 25 Nov 2017 11:42:28 -0500 In-Reply-To: <878teuvgpi.fsf@gmail.com> (Chris Marusich's message of "Sat, 25 Nov 2017 01:40:57 -0800") 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: Chris Marusich Cc: guix-devel@gnu.org Heya, Chris Marusich skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> The Guix system string has the form ARCHITECTURE-KERNEL, because these >> are the two things not explicitly captured by the derivation graph. > > I see. When you say that something is "captured by the derivation > graph," do you mean that it is part of the hash calculation, so it > influences a derivation's store path as well as the derivation's > outputs' store paths? What I meant is that, in the functional model as implemented in Nix/Guix, the derivation graph captures all user-land software that comes into play. But it does not capture the hardware and kernel, both of which are taken from granted. Thus, this system string allows us to represent the dependency on a kernel and hardware architecture. In turn, this allows us to distinguish between, say, the Guile derivation for x86_64 and that for MIPS. > Other than the Guix system string, what things are "captured by the > derivation graph" (either explicitly or implicitly)? For example, is > the ABI captured by the derivation graph? What about the vendor? What > about the executable file format (e.g., ELF vs. some other possibility)? > Anything else? The ABI and file format are entirely (or almost entirely) the responsibility of user-land software (how you configure the toolchain determines what ABI you use, for instance.) Thus they=E2=80=99re necessari= ly captured by the dependency graph; no need to store that information elsewhere. The vendor doesn=E2=80=99t matter on Intel machines. It matters on ARM, but only for specific things like the bootloader and the kernel. >> The =E2=80=9Chf=E2=80=9D in =E2=80=9Carmhf-linux=E2=80=9D denotes an ARM= v7 processor with a hardware >> floating point unit; it does not denote the ABI since the ABI is >> something that=E2=80=99s software-defined. >> >> As it turns out, we map =E2=80=9Carmhf-linux=E2=80=9D to the HF ABI (=E2= =80=9Ceabihf=E2=80=9D), because >> that=E2=80=99s the most sensible thing to do, but we could just as well = map it >> to the old soft-float ABI (=E2=80=9Ceabi=E2=80=9D). > > My understanding is that when a derivation's system is "armhf-linux", it > means that the derivation itself (as opposed to its output) is intended > to be built (i.e., the derivation's builder is intended to be run) on > the "armhf-linux" platform. If the Guix system string does not contain > details like the ABI, then how does Guix differentiate between the case > in which the derivation is built on an ARM system that uses the HF ABI, > and the case in which it is built on an ARM system that uses the > soft-float ABI? It=E2=80=99s the toolchain that shows up in the graph that determines what = ABI is targeted. >> Usually yes, because user-land software doesn=E2=80=99t care about the = =E2=80=9Cvendor=E2=80=9D >> part. It could make a difference to, say, GRUB, for which the =E2=80=9C= vendor=E2=80=9D >> part is important. > > What is the recommended way to package software in Guix when the > software's behavior or the output of the derivation that builds it can > be influenced by the value of the "vendor" part? There are two or three examples of that, which are U-Boot, GRUB, and Linux-libre. We essentially define several package variants for each of these, depending on the target hardware. > For example, suppose I purchase an x86_64-linux server from a vendor > called FooCorp Nothing to worry about in this case. :-) > Yes, I understand. The GNU triplet concept makes more sense to me now. > However, if information like the vendor and the OS/ABI are important > enough to put into the GNU triplet, I still don't understand why we can > get away with omitting those details from the Guix system string. I hope I answered that question! That said, you may get better-informed answers on the GCC or Binutils mailing lists. :-) Ludo=E2=80=99.