In article <[EMAIL PROTECTED]> you write: >The alternative of course is to do only crossbuilds. Is it reasonable >to say that, for platforms where a bootstrap is no longer feasible, a >successful crossbuild is an acceptable test procedure to use instead?
No. I've been playing enough with crossbuilds to know that a crossbuild will show you bugs that do not exist in native builds, and VICE-VERSA. Building a full system natively, compiler-included, is still one of the best stress-test for an operating system. This mind frame, that because the compiler is too slow, it's acceptable to do cross-builds, is killing older systems. Very quickly, you end up with fast, robust systems that are heavily tested through the build of lots of software, and with slow, untested systems that never see a build, and are only tested casually by people running a handful of specialized applications on them. I'm speaking from experience: you wouldn't believe how many bugs we tracked and fixed in OpenBSD on fringe platforms (arm, sparc64) simply because we do native builds and see stuff people doing cross-builds don't see. This is not even the first time I talk about this on this list. Except for embedded systems where memory and disk space don't make it practical to compile anything natively, having a compiler so slow that it makes it impossible to compile stuff natively kills old platforms. Do you know why GCC4 is deprecated on sparc-openbsd ? It's simply because no-one so far has been able to dedicate the CPU time to track down the few bugs that prevented us from switching to gcc 3.x from 2.95. That's right, I said CPU-time. It takes too long to bootstrap the compiler, it takes too long to rebuild the whole system. And thus, it rots.
