From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Cross-compilation, Guix "system", and GNU "triplet" Date: Sat, 25 Nov 2017 13:31:08 -0800 Message-ID: <87bmjqoxk3.fsf@gmail.com> References: <87shd4sduo.fsf@gmail.com> <871sknbxb4.fsf@gnu.org> <878teuvgpi.fsf@gmail.com> <87a7zaxqc1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48569) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIi2i-0003gT-E9 for guix-devel@gnu.org; Sat, 25 Nov 2017 16:31:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIi2f-0006FE-9y for guix-devel@gnu.org; Sat, 25 Nov 2017 16:31:20 -0500 In-Reply-To: <87a7zaxqc1.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sat, 25 Nov 2017 17:42:22 +0100") 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ludo@gnu.org (Ludovic Court=C3=A8s) writes: > 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. > > ... >=20 > 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 necessa= rily > captured by the dependency graph; no need to store that information > elsewhere. >=20 > ... > > It=E2=80=99s the toolchain that shows up in the graph that determines wha= t ABI > is targeted. I think I understand now. I was missing the fact that what ABI you use is determined by how you configure the toolchain. I don't (yet!) know as much about compilation, cross-compilation, and the GNU toolchain as I'd like, so I appreciate you taking the time to explain to me what must have seemed obvious to you. >> 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. OK, that makes sense. >> For example, suppose I purchase an x86_64-linux server from a vendor >> called FooCorp > > Nothing to worry about in this case. :-) Do you say that because if it mattered, we could just define a separate package that takes advantage of the vendor-specific feature, like we might do for U-Boot and GRUB? >> 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! Yes, I think you did. I really appreciate it! > That said, you may get better-informed answers on the GCC or Binutils > mailing lists. :-) Thank you for the suggestion. I'll keep it in mind. It's good to know where to go for help! =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAloZ4R0ACgkQ3UCaFdgi Rp1khhAA0Z63bBK3f6Fc2o3D0rouDcEVKS5/nExNg2fuc/3SE4LsJOMaSIStWeoS AMN0sDGH8TjrnfMmZ6LxBFi8NqTD9mI5slZe+xFnhvbTvtZUCdfeH2d7FRgId42+ Ei3YLjopdGPLaH3BmVIDWZzEBgXjJrRbCg75r/PuLYwZ3n6fr4dQMckNtZb5ujRl 3hhUjmYJJ76Nw2ZENOOZHjY6OMr7Xw5G0enr7lN0CI2jhGge5/S2G0p42QxtHcAJ tpVpIR96Y88Rxsc8bO2Bm/EonxqFvgxiiemWobz4EqcbJecZDoeaun+H4YFEfhxA wgNfn/5akMpJBTt6LUcSdLniqIchh3qW5p4uQW4RswCDAQqJaX577Zjypuqra3M2 Oq5cqSNKYydH/hzadf+K0ACS2n7XA1nRxQn11KHc+TLfJs9VSiSHkS5P6XE9GkeI tCIeYE2K1ms2OhLcCaWAwxVVU02vQaMomOJolXf5fv3nXuJrJNwL9pGxFYl8+u43 xXQhuc5L+PTYldNAbHkQvYiEn6KXd0HlW+ybkpugpDJ64zlhI3im7P+wOMH881LT jyai/q4w+lP1rJt0yc4gjCwMKK/17DT4RPV6OQgETGaTcUw6HuizVo9Ssf4e1wk2 bLLeTg+Y9UAINcsQ6zbhAntfxn3KNxfgEFY7TYSLL0G9A3vf5zI= =lAXu -----END PGP SIGNATURE----- --=-=-=--