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 01:40:57 -0800 Message-ID: <878teuvgpi.fsf@gmail.com> References: <87shd4sduo.fsf@gmail.com> <871sknbxb4.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]:58207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIWxR-0008Bh-0K for guix-devel@gnu.org; Sat, 25 Nov 2017 04:41:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIWxN-00028t-Nj for guix-devel@gnu.org; Sat, 25 Nov 2017 04:41:08 -0500 In-Reply-To: <871sknbxb4.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Fri, 24 Nov 2017 14:50:23 +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 Hi Ludo, As always, thank you for entertaining my questions! 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? I think that's what you mean, but I'd like to make sure. My understanding is that this is precisely the reason why we make the Guix system string a field of each derivation: it ensures that different systems use different store paths, which is good because an x86_64-linux system probably can't build derivations that are intended to be built on an armhf-linux system. 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 =E2=80=9Chf=E2=80=9D in =E2=80=9Carmhf-linux=E2=80=9D denotes an ARMv= 7 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 m= ap 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? Are you saying that we should expect the derivation to build correctly and produce the same output regardless of which ABI is used? Or is there some other mechanism by which Guix differentiates these two cases that I am not aware of? >> My understanding is that multiple GNU triplets can refer to the same >> platform. For example, I believe "arm-linux-gnueabihf" is the same as >> "arm-unknown-linux-gnueabihf" because config.sub in Autoconf translates >> the former to the latter. Do they refer to the same platform? > > 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=9Cv= endor=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? For example, suppose I purchase an x86_64-linux server from a vendor called FooCorp specifically so that I can take advantage of some super cool feature of a piece of software that has been packaged in Guix. It would be unfortunate if I installed that software using a substitute from Hydra, only to find that the super cool feature does not work on my FooCorp machine because the software was not explicitly compiled for the x86_64-foocorp-linux-gnu platform. This is probably a theoretical edge case, but I'm curious to know what the plan is for dealing with situations like this. > Guix doesn=E2=80=99t try to interpret GNU triplets in any way. So when y= ou pass > a triplet to --target, it goes ahead and creates a cross-toolchain for > that triplet. > > If turns out that Hydra has substitutes for the arm-linux-gnueabihf > cross-toolchain, but not for arm-whatever-linux-gnueabihf. I see. That makes sense. > The triplet idea predates GNU/Linux, I think. Back then, it was quite > clear what the OS was: SunOS, AIX, GNU, etc. > > With glibc ported to the kernel Linux, it became useful to differentiate > between =E2=80=9Cgnu=E2=80=9D (i.e., GNU/Hurd) and =E2=80=9Clinux-gnu=E2= =80=9D. User-land software > often only cares about the =E2=80=9C-gnu=E2=80=9D part, but sometimes it = needs to know > about the kernel as well. > > Then people had the idea to abuse the triplet to piggyback information > about the ABI being targeted. There are bits in the toolchain that > interpret it meaningfully. > > I hope it makes sense. :-) 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. Hopefully you can help me to understand what I'm missing. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAloZOqkACgkQ3UCaFdgi Rp2HURAAg1bNXHSNLyRlGkV6f30rp/QMTrDfWawPUXP9fZDtXCrpsj/THHHLrbl8 P0pcoAeX7996ydX4xyh6bxbi9kDKE60qMx3pEdLCoQ/GEGnE0kpFjO08SwUXZARd 8lU48q1oVdixT6Uwy3YnFMwDq+5CzaPKfavAuFwTFVSFBmkUFjtrByAriJWkxJjZ 79+pDlqVBwiU1J1N2KNwACD2t9mQAFWE11InGUPGshZmhnZOygOEI7ZSqtuTJEmV 2sqEH1svVvM8p6hOPmuc7fuQ7oNbRivwf2UpGvGH2G5s2O5sgCkeV5Mw9OnapnJ9 dcYtruAKF3ve8PekitdWu9aXdO4/+2Hi7TOdjlxhiZcsUyEWsrzlQfzukWlTkKw4 /kKu03Jr1r3SwNz2rSDlVnIY8JT/q/ixFNE8rwTp5IFuT7YbbGM6fg0M28hSAZ6s Sb8S7jWLbRt9nrVD1FpxWRkm5x9k4QTM5i+ikNnr//GrsgD9081qAKcvwHgx+QGM aWlzD+xBgyqhGEOW0h5FtP8SajCk9gCKlDNsJLHW4SsWJc5h0oOR3qaai0lpn+Gx zRWhXwprc85hq1ELF6G6tGtWILuhHaqq0m3FyVytYmWI1wkSGS1M5e91basY2iG+ Qtq4h4hwPGdj4osILSThtqK+Ps6sORTNperHefiMH0qmkpBNvFw= =T2Pc -----END PGP SIGNATURE----- --=-=-=--