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.
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
