[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cross-building GuixSD (and maybe using pre-built toolchains)

From: Ludovic Courtès
Subject: Re: Cross-building GuixSD (and maybe using pre-built toolchains)
Date: Wed, 31 Aug 2016 22:04:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Hi Paul,

Paul Boddie <address@hidden> skribis:

>> > Are there any recommended methods of running guix-daemon in a chroot and
>> > 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?
>> 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.
>> Now, if you really want it, I can’t think of any reason why guix-daemon
>> wouldn’t 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 
> deciding to install stuff in places I would rather keep "clean", and to use 
> 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 
> target machine using distcc as a client and having distcc servers cross-
> compile code for the target architecture. That seems to require the 
> coordinating host to be running Arch/Parabola, which then means that some 
> bootstrapping needs to be done already. Could a similar thing be done with 
> GuixSD?

Yes, using offloading:

If your master node is x86_64 and its machines.scm lists a mips64el
machine as in the example above, then “guix build foo -s mips64el-linux”
automatically offloads to that mips machine.  (This is the mechanism our build farm uses.)

>> That’s also an option: you can simply cross-build the packages that you
>> need and copy them to the target machine.
>> We make sure core packages can be cross-built to the architectures we
>> support (currently x86_64, i686, armhf, and mips64el).  However, there’s
>> no guarantee that cross-building works for other targets, or that
>> non-core packages cross-build at all.  We’d definitely welcome patches
>> in this area, though.  :-)
> Right. So you'd cross-build things like the kernel, libc, gcc, binutils, 
> maybe 
> some other things (the bootstrapping discussed above). Then bring up the 
> target machine and hopefully have enough to start building packages somehow. 
> Does that sound correct?

When bootstrapping a new architecture, we cross-build the relevant
“bootstrap binaries”, which are statically-linked tools such as GCC,
Guile, as well as libc, and from there we can start building natively:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]