On Wed, Aug 24, 2005 at 11:42:28AM +0200, Olaf van der Spek wrote: > And what about cross-compiling?
Cross-compiling is no magic wand that can save us from the slow architectures. There are quite a number of problems with cross-compiling: * Many packages don't support cross-compiling, and those that do may have bugs in their makefiles that make cross-compiling either harder or impossible. * You can't run the test suites of the software you're compiling, at least not directly. * There's a serious problem with automatically installing build-dependencies. Dpkg-cross may help here, but there's no apt-cross (at least not TTBOMK); and implementing that may or may not be hard (due to the fact that build-dependencies do not contain information about whether a package is an arch:all package or not). * By using a cross-compiler, by definition you use a compiler that is not the same as the default compiler for your architecture. As such, your architecture is no longer self-hosting. This may introduce bugs when people do try to build software for your architecture natively and find that there are slight and subtle incompatibilities. Hence the point of trying out distcc in the post to d-d-a; that will fix the first three points here, but not the last one. But it may not be worth the effort; distcc runs cc1 and as on a remote host, but cpp and ld are still being run on a native machine. Depending on the program being compiled, this may take more time than expected. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
