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

[James Haigh]

On 09/02/15 16:01, Harald van Dijk wrote:
> On 09/02/2015 15:57, James Haigh wrote:
>> [...]
>> 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.
Exactly.
> 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.
The word I'm looking for is to refer to the entire compiler system;
toolchain seems to fit, but maybe it's confusing if it has specific
connotations/implications to someone familiar with compilers. My
understanding of compilers is very naïve and on the level of Lego
bricks... or perhaps tombstones are a more fitting analogy:
https://en.wikipedia.org/wiki/Tombstone_diagram
:-)
> 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.
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.
    So with GNAT for example, you'd either implement the compilation
isolation, in GNAT, or you'd use virtualisation and keep the
cross-compilation package support, in GNAT.
    Anyway, I'm no expert and would not be able to implement either of
these approaches (or anywhere between the 2 if they can be seen as
endpoints of a spectrum). I'm just throwing it out there as a suggestion
that it may be best to implement such a solution in an upstream compiler
project. Possibly.

Best regards,
James Haigh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150209/30c7a83e/attachment.html