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

Tue Feb 10 16:16:14 CET 2015

I used this with the raspberry pi, and I made notes in the wiki at that time.

On Tue, Feb 10, 2015 at 03:14:10PM +0000, Wout Mertens wrote:
> There's another option : build natively with distcc pointing to
> cross-compilers on x86 boxes. All the configuration etc happens natively
> and the compiles themselves are sped up. I wonder if that's the approach
> Vladimír Čunát took earlier? He made the notes on how to set up distcc for
> raspberry pi on the wiki iirc.
> 
> Yet another option : run the above option in qemu, running the whole thing on
> an x86 box with the heaviest lifting done natively.
> 
> These only speed up C/C++ of course.
> 
> Wout.
> 
> On Mon, Feb 9, 2015, 5:01 PM Harald van Dijk <harald at gigawatt.nl> wrote:
> 
> > On 09/02/2015 15:57, James Haigh wrote:
> >
> > On 09/02/15 14:16, Harald van Dijk wrote:
> >
> > On 09/02/2015 14:55, James Haigh wrote:
> >
> > On 28/01/15 07:42, Luke Clifton wrote:
> >
> > Hi Bjørn,
> >
> >  I have read that thread. I agree with you 100% that native builds (on
> > real or virtual hardware) is the only way this can work. Upstream doesn't
> > usually care if their software can cross compile, and they can't maintain
> > it themselves even if they did. Sometimes it isn't even an option, e.g. GHC
> > still can't cross compile template Haskell yet.
> >
> > I don't understand why cross-compilation is even a thing, other than
> > decades of false assumptions being baked into compilers.
> >     As I understand, if a compiler (and by ‘compiler’ I'm referring to the
> > whole toolchain required for compilation) is taking source code and
> > compilation options as input, and giving object code for the specified
> > platform as output, it is called ‘cross-compiling’ if the specified target
> > platform is different to the platform that the compiler is running on. If
> > GCC is running on ARM, compiling code ‘natively’ to ARM successfully, it is
> > counterintuitive that it would fail to build for ARM if GCC is running on
> > x86. And vice versa. A compiler should produce object code for a target
> > platform that implements the source code – it may not have the same
> > efficiency as the output of other compilers (or with other compilation
> > options), but should have the same correctness when execution completes. If
> > the source code being compiled is a specific version of the GCC source code
> > itself, and it is compiled for both x86 and ARM, then if the compilation is
> > computationally correct, both compilations of GCC should produce programs
> > that, although will compute in a different way and with different
> > efficiency, should give the exact same object code when given the same
> > source code and parameters. So if the target platform parameter is ARM,
> > they should both build exactly the same ARM machine code program.
> >
> > All of this is true, but the toolchain usually doesn't have any problems
> > with cross-compilations.
> >
> >     However, evidently this is not the case unfortunately. So the
> > compilers or their toolchains are, in essence, receiving the platform that
> > they are running on as ‘input’ to the build, and making assumptions that
> > this build platform has something to do with the target platform. I.e. they
> > are _aware_ of the platform that they're building on, whereas
> > theoretically, they shouldn't be. Apparently this has a lot to do with
> > configure scripts.
> >
> > The configure scripts, or similar machinery in non-autoconf packages, are
> > part of the package, not part of the toolchain. Many programs use runtime
> > checks in configure scripts. A trivial example that hopefully doesn't exist
> > in any real package:
> >
> > If a package only compiles on platforms where sizeof(int) == 4, or where
> > special code is needed on platforms where sizeof(int) != 4, might try to
> > detect those platforms by compiling and linking
> >
> > int main(void) {
> >   return sizeof(int) != 4;
> > }
> >
> > and then executing it. If the execution succeeds (i.e. returns zero), then
> > sizeof(int) == 4. If the execution doesn't succeed, then the configure
> > script assumes that sizeof(int) != 4, even though it's very well possible
> > that the only reason that execution fails is that the generated executable
> > is for a different platform.
> >
> > Other examples are build environments that build generator tools at
> > compile time, and run them to produce the source files to compile at run
> > time. The generator tool must be compiled with the build compiler, not with
> > the host compiler, or execution will fail when cross-compiling. Still, many
> > packages build such tools with the host compiler anyway, because upstream
> > only tests native compilations. This too is not an issue with the toolchain.
> >
> > But what I'm saying is that if the package succeeds in compiling natively
> > but fails to cross-compile, then this is an issue with the
> > compiler/toolchain. Yes it can be solved by writing configure scripts that
> > support cross-compiling, but really, the compiler toolchain should isolate
> > this such that the compilation is deterministic regardless of build
> > platform.
> >     In your example, I'm saying that it should be the job of the compiler
> > toolchain to ensure that ‘sizeof(int) == 4’ gives the correct result for
> > the target platform. If the only feasible way to do this deterministically
> > is to run the configure scripts in a virtual machine, then this Qemu
> > technique should be considered part of the standard compiler toolchain.
> > That way, the determinism and isolation from the build platform is achieved
> > in the compiler toolchain, and upstream packages do not have to make any
> > effort to support cross-compilation beyond supporting the target platform.
> >
> > Oh. So the current toolchain does support cross-compilations, but requires
> > packages to be aware of it and handle it appropriately. You're saying
> > packages shouldn't need to be aware of it. Okay, that's possible, but
> > that's a proposal for an entirely different toolchain (but you're not using
> > the word in the sense most people do), not necessarily a problem with the
> > current toolchain. It does support what you claim it doesn't support, it
> > just doesn't support what you want it to support.
> >
> > What you're suggesting effectively means dropping all support for
> > cross-compilations everywhere, because every package would see a native
> > environment. You can do that if you like, with no support needed from any
> > package whatsoever, and what's more, with no support needed from Nix
> > whatsoever either. You can simply run Nix itself in a Qemu environment. The
> > only time cross-compilations then become an issue is with bootstrapping. I
> > don't know about GHC, but for example GNAT is written in Ada, so you need
> > GNAT for your host platform in order to build GNAT for your host platform,
> > and by dropping support cross-compilations, you would not be able to use
> > the GNAT for your build platform to build the GNAT for your host platform.
> >
> > Cheers,
> > Harald van Dijk
> >  _______________________________________________
> > nix-dev mailing list
> > nix-dev at lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >

> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

-- 
PGP key D4831A8A - https://emailselfdefense.fsf.org/