> * 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). scratchbox solves these problems. > * 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. > I have never seen nor heared about such a case. IME this is extremely rare (if it happens at all). The only way to know if this is a real problem is to try using cross compiling and verify against existing native compiled binaries. Unfortunately the verify bit is quite annoying as a simple cmp will likely fail because of things like build date, build number, etc included in the binary. For packages which have a testsuite, this testsuite could be used as the verification step. > 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. > Which is why scratchbox is a more interesting solution, as it only runs those parts on target which can't be done on the host. Cheers, Peter (p2).
Attachment:
signature.asc
Description: Digital signature