[Nix-dev] A few questions about ARM support and NixOS on a Chromebook

[Luke Clifton]

On 10 February 2015 at 03:58, James Haigh <james.r.haigh at gmail.com> wrote:

> Even for bootstrapping, it should still be possible to do without package
> support for cross-compilation. Compiling entirely within Qemu is one,
> perhaps crude, way of ‘fixing’ the build platform isolation problem in
> compilers. All that's really needed is for the configuration checks and
> tests to be ‘given’ the answers that would be obtained on the target
> system, yet the tools that are running them could still be compiled to and
> running in the architecture of the build system. Theoretically, there may
> be no virtual machine involved at all, and hence no architecture
> bootstrapping problem.
>     However, seeing as, when bootstrapping, the package that we want to
> compile is the compiler itself, it doesn't really matter whether this is
> done by having package support for cross-compilation (in the compiler
> package), or by implementing the isolation in such a way as to allow the
> compiler to run natively while compiling. In other words, in this specific
> case, whether it is the compiler or the package that is the one supporting
> the cross-compilation, it is the same thing! :-D The difference being which
> way is easiest to implement reliably versus which is most efficient.
>     I'd imagine that an implementation that only isolates the calls to the
> build system and does not require running the compiler in the target
> architecture would be the absolute the most efficient, but that the method
> where everything beyond the bootstrap is run in a virtual machine is the
> easiest to implement. There are probably also quite a few middle-ground
> options where some components are running natively and some are being
> virtualised.
>

In order to compile within Qemu, you first need to build the kernel, and
the compiler (and a few other base tools). This is what is meant by
bootstrapping, and you have to do this with real cross-compilation because
you don't yet have a virtual machine on which to natively run the build
process. Luckily, these basic bootstrapping packages have very good support
for cross-compilation upstream. The Linux kernel is a breeze to cross
compile. Once you have the kernel, gcc, binutils and make, you are more or
less ready to proceed with building any package natively (in a virtualised
environment).

The problem with your suggestion of a method which "isolates the calls to
the build system" is that because we don't have control over what build
systems other people are using (CMake, make, just a bash script, their own
bootstrap language) we have no way of controlling what they do in there
(anything can call uname -a, but what where they trying to discover?), and
there are about 37 bazzillion ways that things can go wrong. Trust me, I
have tried. In fact, Linux has great support for emulation at the exec
level. You can make your x86 linux platform understand ARM binaries and
execute them. This get's you a long way, the issue with sizeof(int) == 4 is
solved, but there are still 37 bazzillion - 1 other things that can still
go wrong.

At one point I had a chroot which contained an ARM system, but some of the
binaries I replaced with native versions for speed increases. I had built
GCC so that it would work in an ARM chroot, building ARM binaries, but
itself an x86 binary. This system actually worked really well... until I
hit the next problem. I can't remember exactly what it was now, but even
with a chroot, you had to bind a whole bunch of other files into the chroot
(some /dev/ stuff etc.). Eventually packages manage to find some way of
figuring out that they are not really running on an ARM machine, and your
build fails (in sometimes not obvious ways).

The problem is, we have no way of knowing what information the build
scripts are trying to figure out when they call something like uname -a.
Maybe they did want to know what the build machine was, maybe they wanted
to find out what the target was. Or, as is often the case, they wanted to
determine both. We can't just put a version of uname into the environment
that does the "right thing" because there is no "right thing" because
everyone is using it for a different purpose.

So basically, the only way that I can see this working is to have proper
cross compilation support for the basic stuff, and the run the rest
natively.

Regards,

Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150210/42b6df57/attachment.html