> > A much faster solution would be to use distcc or scratchbox for > > crosscompiling.
> Debian packages cannot be reliably built with a cross-compiler, > because they very frequently need to execute the compiled binaries as > well as just compile them. Umm, that is the _exactly_ the problem scratchbox was written to solve. The idea is to have a chroot with crosscompiler and all the flex/bison/document generation/etc tools available as host binaries, while the actual libs linked against are as the target arch debian packages. When a binary actually needs to be run in the target arch, it is executed either with qemu or via sbrsh and nfs on a real target arch machine. As a consequence, most compilations are almost as fast crosscompiled as on the host machine. The ones that are still slow, are the ones that have a complex testsuite, like perl... The are a few drawbacks why it currently can't be really used as debian buildd: First, host tools are somewhat hacked versions of the same tools in debian. For proper debian usage, they should be the same versions as what has been last uploaded to debian. The other one is that the toolchains should also be generated from debian packages.. Currently the build process is kinda ad-hoc.. Incidentally the first problem should be solvable with the multiarch proposal, and the toolchains need to be polished anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]