Hi Michael and Heinrich, sorry for missing this bug for so long, neither of the pings got to me and I can't even find them in #debian-qemu now that I actively search them :-/ Anyway - Sergio forwarded your ping to get my input on this.
First of all, this is all super old, and changed a bit over time each time something failed. No one of us is very deeply into the build or usage of these vdso files. After all they are a performance optimization to speed up execution with less syscall overhead. But for that they need to be per target architecture. Due to that you need all the cross compilers. Hence Michael said that he no longer needs this for Debian, as there all the cross compilers are available (as for Ubuntu). But Ubuntu is different in regard what we can depend on - remember this is usually only touched when breaking, last time it was Sergio who spotted a failure after the most recent changes and for the time being none of us found a better solution than adapting to keep them to break the dependency. Here is an example list of related build dependencies with qualifiers by the build profile: debian/control-in:179: gcc-arm-linux-gnueabi <!pkg.qemu.use-upstream-vdso>, libc6-dev-armel-cross <!pkg.qemu.use-upstream-vdso>, debian/control-in:180: gcc-hppa-linux-gnu <!pkg.qemu.use-upstream-vdso>, libc6-dev-hppa-cross <!pkg.qemu.use-upstream-vdso>, debian/control-in:181: gcc-i686-linux-gnu <!pkg.qemu.use-upstream-vdso>, libc6-dev-i386-cross <!pkg.qemu.use-upstream-vdso>, debian/control-in:182: gcc-loongarch64-linux-gnu <!pkg.qemu.use-upstream-vdso>, libc6-dev-loong64-cross <!pkg.qemu.use-upstream-vdso>, debian/control-in:183: gcc-powerpc64-linux-gnu <!pkg.qemu.use-upstream-vdso>, libc6-dev-ppc64-cross <!pkg.qemu.use-upstream-vdso>, debian/control-in:184: gcc-riscv64-linux-gnu <!pkg.qemu.use-upstream-vdso>, libc6-dev-riscv64-cross <!pkg.qemu.use-upstream-vdso>, debian/control-in:185: gcc-s390x-linux-gnu <!pkg.qemu.use-upstream-vdso>, libc6-dev-s390x-cross <!pkg.qemu.use-upstream-vdso>, debian/control-in:186: gcc-x86-64-linux-gnu <!pkg.qemu.use-upstream-vdso>, To go a bit deeper on that, building in arch-all on x86 (independent or not) allows us to "only" need the cross compilers on x86. And not cross compilers from all to all architectures :-). Here a short overview of these dependencies and where they could be resolved: $ rmadison -u ubuntu -s questing gcc-arm-linux-gnueabi gcc-hppa-linux-gnu gcc-i686-linux-gnu gcc-loongarch64-linux-gnu gcc-powerpc64-linux-gnu gcc-riscv64-linux-gnu gcc-s390x-linux-gnu gcc-x86-64-linux-gnu gcc-arm-linux-gnueabi | 4:15.1.0-1ubuntu1 | questing/universe | amd64, arm64, ppc64el gcc-hppa-linux-gnu | 4:15.1.0-1ubuntu1 | questing/universe | amd64, arm64, ppc64el gcc-i686-linux-gnu | 4:15.1.0-1ubuntu1 | questing | amd64, arm64, i386, ppc64el, s390x gcc-loongarch64-linux-gnu | 4:15.1.0-1ubuntu1 | questing/universe | amd64, arm64, ppc64el gcc-powerpc64-linux-gnu | 4:15.1.0-1ubuntu1 | questing/universe | amd64, ppc64el, s390x gcc-riscv64-linux-gnu | 4:15.1.0-1ubuntu1 | questing | amd64, arm64, i386, ppc64el, riscv64, s390x gcc-s390x-linux-gnu | 4:15.1.0-1ubuntu1 | questing | amd64, arm64, i386, ppc64el, s390x gcc-x86-64-linux-gnu | 4:15.1.0-1ubuntu1 | questing | amd64, arm64, i386, ppc64el, s390x So for the time being as Sergio wrote in [1], we wanted to accept this as-is for the time being and were considering to revisit later. I think some could be simplified today (as you see below we do build them now), but I do not yet see how we'd not need them for non-x86 builds. So far there has neither been a major change in how this works nor a resource to investigate more deeply and lengthy. > Are you aware these binaries are *not* > used on debian trixie, but *are* used on ubuntu because > ubuntu does not have separate arch-all build? That is correct, and the very important word here is "separate". Because the difference for us is that arch-all is just a step of x86. We can not depend on the outcome of the arch-all step in the other architectures build, the current compromise was chosen. AFAIU these files are only used to break the dependency cycle at build. And yes, that way something might slip as we all have seen in the infamous example you quoted - but at least the actual final content is built. If you look into a recent build log [2] for 'vdso-updated' and the steps before you'll see that this is not taken as-is from the source. Here comparing the one from source to the one shipped in a build from that source, to show that these are the new ones. $ md5sum /root/qemu-10.1.0~rc2+ds/linux-user/riscv/vdso-64.so /tmp/linux-user-vdso.tar.gz/linux-user/riscv/vdso-64.so df8aa9381fdc9a53794bb31a600051ba /root/qemu-10.1.0~rc2+ds/linux-user/riscv/vdso-64.so ee42fa7b62a2c9c97527a5f3d28203a8 /tmp/linux-user-vdso.tar.gz/linux-user/riscv/vdso-64.so TL;DR AFAIU: - Debian: ignores them, arch-indep builds them new into qemu-system-data, that is then used in other arch builds - Ubuntu: can't B-D on qemu-system-data from same source, hence arch builds us the one from source, but for delivery in qemu-system-data they are ignored too and arch-indep builds them I'm not sure about a way out - maybe moving them to an entirely different source and building it there comes to mind, similar to what was done with for libslirp and userspace networking - but here that might cause all kind of interesting dependency issues. Depending on the older vdso from whatever the former version was? ... I do not know :-/ This is all brittle knowledge, again remember it is usually only touched when it breaks :-) And these days I'm covering as a side effort with very limited time. I outlined how I think it works, where we are and what needs to be done. If I'm wrong somewhere please do not chastise but teach me. If there is a solution to further eliminate usage of the pre-built elements at build time in Ubuntu, I think we'd all be happy to remove them. Until then I highly appreciate Michael kept them around as is to allow us to break the dependency cycle and not ship but use them at build time. [1]: https://git.launchpad.net/ubuntu/+source/qemu/commit/?id=f6428410aabd40e9b3c4889a6a157fb687294df8 [2]: https://launchpadlibrarian.net/804034172/buildlog_ubuntu-questing-amd64.qemu_1%3A10.0.2+ds-1ubuntu2_BUILDING.txt.gz -- Christian Ehrhardt Director of Engineering, Ubuntu Server Canonical Ltd
