help-guix
[Top][All Lists]
Advanced

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

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


From: Paul Boddie
Subject: Re: Cross-building GuixSD (and maybe using pre-built toolchains)
Date: Tue, 30 Aug 2016 23:26:38 +0200

Hello,

(Quoting a discussion on the development list, which proved rather too active 
for me to follow. Sending to this list at Ludo's suggestion.)

> Paul Boddie <address@hidden> skribis:
> > I was looking at the documentation, which is rather more helpful than
> > most distributions when it comes to describing how the actual
> > distribution archives are built, and I figured a few things out about
> > guix-daemon. However, I'm doing all my work in a chroot - I don't want
> > to "make install" and populate various locations on my main system - and
> > this doesn't seem to be entirely compatible with the recommended way the
> > daemon is used. Specifically, the daemon does not seem to be able to
> > build anything unless I specify the -- disable-chroot flag.
> 
> How does guix-daemon fail exactly?  If needed, could you strace it to
> get more details on what’s going on?

I could try and take a look at this.

> > 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. I guess I could instead have separate 
partitions for /usr and other things and make them read-only, and so on, but 
I'm not sure many people do this these days.

Then again, I do see people wanting to run Guix on other distros, so perhaps I 
should just accept that it doesn't need to run inside a chroot itself.

> > One thing that looks very promising is the ability to cross-bootstrap the
> > system, and I did manage to get that started for a new architecture
> > (mipsel) by performing some modifications suggested in the documentation
> > [1], running guix-daemon with the --disable-chroot flag, and then
> > running this:
> > 
> > guix build --target=mipsel-linux-gnu bootstrap-tarballs
> > 
> > However, not wanting to leave my computer switched on all night, I
> > stopped the build after a while. I can understand the need to bootstrap
> > things like toolchains, but given that I am running Debian which has
> > cross-toolchains for mipsel, I wondered if I could short-circuit this
> > process by employing pre- built toolchains. Would this be possible?
> 
> No.  The approach we’re taking is to have a self-contained distro, and
> that’s where we get all the fruits of the “functional paradigm”
> described in the manual.
> 
> It’s surely an annoyance when bootstrapping an architecture for the
> first time.  Once it’s in place though, it’s OK.  You could have build
> machines for that architecture publishing binaries to users (via ‘guix
> publish’).

I was really only looking for a short cut here, I admit. And if you have a 
robust way of building toolchains, that's actually a great thing, because it 
can be difficult to do repeatably (tracking the evolution of the software, 
dealing with platform issues), and people still download random binary 
toolchains for such purposes even today because it is a scary thought to build 
their own from source.

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?

I do understand the "self-contained" motivation: it's exactly what Debian and 
other distros insist upon, although I'd argue that it's also what holds such 
distros back from properly supporting cross-compilation. (I did follow the 
Emdebian project for a while, and it just seemed like very punishing work that 
tended to interest very few people, sadly.)

> > Finally, it seems to be the case that the workflow involves building a
> > bootstrapped minimal system and then natively building packages. Or have
> > I misunderstood the process?
> 
> Correct, this is the process to port the distro to a new platform.

Understood.

> > Is it possible to cross-build all of the packages in the distribution?
> 
> 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?

> HTH!

Yes, I think it does. Thanks for the response and sorry once again for not 
replying before now!

Regards,

Paul



reply via email to

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