ludo@gnu.org (Ludovic Courtès) writes: > Hi Greg, > > Greg Troxel writes: > >> I don't think that's true at all. It could be that for running Linux on >> arm pdas that's what most people do, but for the far more general case >> there is normal cross compiling as autoconf has supported for years. >> >> I am working on a project that does cross builds of a lot of software; >> none of it uses scratchbox. > > You may well have more experience than I have. Or maybe just different... I don't really understand the compiler. >> I can certainly see the point of something like scratchbox, to ease the >> process and work around software that has non-cross-clean build systems. >> But I wouldn't say it's time to give up on the normal/traditional way. > > How would you handle this particular case in a "cross-clean" way? The > problem is that we need a Guile to compile the compiler. Do we just need a (reasonable) guile, or do we need to run the target just-built guile itself? I saw some discussion about finding stack offsets, and that's perhaps different. I will use the terms 'host' and 'target' to describe the system one is doing the build on, and the the system that the resulting guile runs on. autoconf would call this 'build' and 'host'; 'host' refers to the machine for which a compiler is built, and target to what the compiler outputs. But we aren't really building a compiler in that sense, maybe. > I think it's not unusual to use just-built binaries to produce some > intermediate source files, especially in the area of interpreters and > compilers. How do others handle it? Yes, this is normal. I'll point out that some of my experience comes From the netbsd build system (to build the OS), and that experience affects my opinions. In NetBSD, basically all builds are cross, even if host==target, in that the host toolchain is used to build the NetBSD toolchain with the desired target, and then that is used to compile the system. One can build for other architectures, and from different host platforms in the same way. One of the things that has to be worked out to make a cross system function is the notion of 'host tool', which is a program that is compiled for the host. An example from netbsd is the time zone compiler, which shows up as nbzic in tools/bin. There's only one such binary even if you build for sparc64, i386, and alpha on an amd64 host. There are three compilers, though; each runs on amd64 and produces separate output. > IIRC GCC stage N uses `xgcc' from stage N-1 in the non-cross case. How > does it work in the cross-compilation case? There's a separate bootstrapping problem for compilers, which I think is about building gcc with host cc, and then building gcc with gcc, so that you get a gcc-compiled binary in the end. With cross, I think you have to build a gcc with target=host and then use that to build gcc with target=target, but I'm not sure. So, building guile probably needs either to build guile as a host tool if host != target, preferably in an objdir, and then that can be used. take a --with-guile that points to a working host guile, and people doing cross builds will have to build guile first. This is not really all that differnet from having to build a cross gcc first, and would be ok with me (as a cross user - my system doesn't have guile, but if it worked that way it would be fine). This can be the default behavior if autoconf's build and host (my host and target) differ. I suppose the host=target case can use the same guile as the tool and the output, because the compiler is additional to the interpreter. If people use scratchbox, then the build is apparently not cross, even if the gcc that is invoked is cross. So this shouldn't hurt.