On 10 February 2015 at 03:58, James Haigh <[email protected]> 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
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
