On 2022-09-06 14:44 +0000, Warlich, Christof wrote: > I resorted to use qemu-user emulation > To speed things up, I started to mess with the armhf container by > replacing the “native” armhf GCC with its related cross-GCC > 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 > But what else needs to be changed to armhf-ify the amd64 > container? uname comes to mind, and probably dpkg? This is not a new idea. Various people have trodden this path before over the past decade or so. But I have forgotten the names if I even knew them (I forget everyone's names these days) so would have to look through the archives to point you at relevant threads. In general any tool that does not have architecture-dependent outputs can run the native version. I have never personally explored this space beyond swapping the toolchain and bash so can't provide any useful info on exactly what the minimum set of stuff that you can replace and still have things work. You might want to look into what OBS does as it uses this technique, and they presumably have good knowledge of how much can reliably be replaced with native binaries. In general I would support what Johannes and Helmut said. In the long term we'll all do better by actually fixing the core problems, even though they can be hard (gobject introspection - we are looking at your cross-ignoring design). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature