From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Cross-building GuixSD (and maybe using pre-built toolchains) Date: Wed, 31 Aug 2016 22:04:35 +0200 Message-ID: <87inugn1rg.fsf@gnu.org> References: <201608302326.38349.paul@boddie.org.uk> 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]:41082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfBkb-0005XL-Be for help-guix@gnu.org; Wed, 31 Aug 2016 16:04:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfBkV-00023e-47 for help-guix@gnu.org; Wed, 31 Aug 2016 16:04:44 -0400 In-Reply-To: <201608302326.38349.paul@boddie.org.uk> (Paul Boddie's message of "Tue, 30 Aug 2016 23:26:38 +0200") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Paul Boddie Cc: help-guix@gnu.org Hi Paul, Paul Boddie skribis: >> > Are there any recommended methods of running guix-daemon in a chroot a= nd >> > have it create new chroots, or do I have to use some kind of >> > virtualisation or container technology? Is any kind of >> > fakeroot/fakechroot mechanism supported? >>=20 >> I think few people do this, on the grounds that Guix is rather >> non-intrusive: it stores all its stuff in /gnu/store and /var/guix. So >> if you want to get rid of it, all you have to do is delete those two >> directories. The rest of the system is untouched. >>=20 >> Now, if you really want it, I can=E2=80=99t think of any reason why guix= -daemon >> wouldn=E2=80=99t run in a chroot. It currently requires root privileges, >> precisely so that it can set up a chroot, separate name spaces, and so >> on, but that could work in a chroot too. > > OK. I tend to run things in chroots for basic protection against things=20 > deciding to install stuff in places I would rather keep "clean", and to u= se=20 > different distro versions and packages. Precisely: Guix only ever touches /gnu/store, /var/guix, and optionally /etc/guix; nothing else, I swear. ;-) > I noticed that Arch Linux and its relative Parabola GNU/Linux support the= =20 > target machine using distcc as a client and having distcc servers cross- > compile code for the target architecture. That seems to require the=20 > coordinating host to be running Arch/Parabola, which then means that some= =20 > bootstrapping needs to be done already. Could a similar thing be done wit= h=20 > GuixSD? Yes, using offloading: https://www.gnu.org/software/guix/manual/html_node/Daemon-Offload-Setup.h= tml If your master node is x86_64 and its machines.scm lists a mips64el machine as in the example above, then =E2=80=9Cguix build foo -s mips64el-l= inux=E2=80=9D automatically offloads to that mips machine. (This is the mechanism our hydra.gnu.org build farm uses.) >> That=E2=80=99s also an option: you can simply cross-build the packages t= hat you >> need and copy them to the target machine. >>=20 >> We make sure core packages can be cross-built to the architectures we >> support (currently x86_64, i686, armhf, and mips64el). However, there= =E2=80=99s >> no guarantee that cross-building works for other targets, or that >> non-core packages cross-build at all. We=E2=80=99d definitely welcome p= atches >> in this area, though. :-) > > Right. So you'd cross-build things like the kernel, libc, gcc, binutils, = maybe=20 > some other things (the bootstrapping discussed above). Then bring up the= =20 > target machine and hopefully have enough to start building packages someh= ow.=20 > Does that sound correct? When bootstrapping a new architecture, we cross-build the relevant =E2=80=9Cbootstrap binaries=E2=80=9D, which are statically-linked tools suc= h as GCC, Guile, as well as libc, and from there we can start building natively: https://www.gnu.org/software/guix/manual/html_node/Porting.html Ludo=E2=80=99.