[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Speedup when using qemu to cross-build packages.

Hi all,


I need to rebuild some several hundred Debian packages for amd64, arm64, armhf and mipsel. This works pretty well for all native (i.e.amd64) packages, but as cross-building seems to only function for less than half of the packages, I resorted to use qemu-user emulation within architecture-specific docker containers to fake a native build environment for the other architectures. But while this _does_ work quite reliably, it’s certainly dead slow: A clean build of e.g. gcc-10 for armhf takes almost a week!


To speed things up, I started to mess with the armhf container by replacing the “native” armhf GCC with its related cross-GCC (i.e. gcc-10-arm-linux-gnueabihf:amd64) with all its dependent libraries from amd64: Multiarch is my best friend here 😊. Doing the same for g++ and binutils gave quite a performance boost, but the build was still much slower than a real native build. Further investigation showed that e.g. configure-scripts are still damn slow, so I also replaced the armhf bash with the amd64 bash (and a few other binaries) …


Ok, coming to the point: As the build speed for the foreign architectures is still far from being optimal even with my hacks, I would rather like to do things the other way round, i.e. starting from an amd64 container, but making it “think” to be an armhf container with minimal changes, i.e. with as much as possible adm64 executables left over, to achieve optimal speed. GCC and the like would still need to be replaced by their cross-counterparts generation for armhf almost the same way as described above, but what else comes to mind that needs to be “fixed”? Certainly, apt must be replaced by apt:armhf to make e.g. “apt-get build-dep” install the build dependencies for armhf instead of amd64 … (note that even apt-get build-dep --host-architecture=armhf fails for quite a few packages!). But what else needs to be changed to armhf-ify the amd64 container? uname comes to mind, and probably dpkg?


Finally, I may certainly be entirely off the rocker with my idea, maybe just because cross-building packages _does_ always work, but I’m just doing it wrong? But _if_ cross-building _is_ a known issue and considering how far I already got with my initial speedup approach (e.g. by partly replacing armhf executables with amd64 executables), I would very much like to get some feedback from more experienced Debian experts. And after all, as reliable and timely cross-builds of all Debian packages does not seem to be an unusual desire to me, maybe there is something out there already that does the job but that I so far have totally missed?


Thanks a lot for your patience reading this,



Reply to: