On Wed, Mar 25, 2026 at 12:21:27PM +0100, Philippe Mathieu-Daudé wrote: > On 25/3/26 11:24, Peter Maydell wrote: > > On Wed, 25 Mar 2026 at 09:19, Daniel P. Berrangé <[email protected]> > > wrote: > > > > > > On Wed, Mar 25, 2026 at 11:08:41AM +0300, Michael Tokarev wrote: > > > > On 20.03.2026 09:45, Michael Tokarev wrote: > > > > > Hi! > > > > > > > > > > Is it intentional that qemu does not build utilities on 32bit hosts > > > > > anymore? > > > > > > > > This is > > > > > > > > commit 372ec46b9f1215f48a4717f2b7ed969f65bfadc6 > > > > Author: Richard Henderson <[email protected]> > > > > Date: Thu Dec 18 09:56:27 2025 +1100 > > > > > > > > meson: Reject 32-bit hosts > > > > > > > > 32-bit hosts have been deprecated since 10.0. > > > > > > > > How would one build qemu-img and especially qemu-guest-agent, say, > > > > on i386 or armhf? > > > > > > > > I tried removing this error message from meson.build (in $subject), > > > > but it fails to build even the qga due to errors in atomic.h, - > > > > even if these aren't used by qga. > > > > > > > > That smells like a bad decision, - to drop qga and qemu-img support > > > > on 32bit architectures. Especially qga. > > > > > > IMHO dropping the block related tools is reasonable, as if you keep > > > that, the dependencies that need to remain 32-bit compatible ripple > > > out across a very large part of the codebase. > > > > > > Not having qga though feels like a pretty undesirable consequence, > > > given our message overall is that we were dropping host support but > > > keeping 32-bit emulation. > > > > Yes, I'm not sure we quite realised that we would be no longer > > building QGA for 32-bits. How much effort would it be to > > reinstate that? > > From the commits in 5053e0a65db...90e2e8ada7c we'd need to (partially) > revert various of the buildsys ones (meson & configure). > > Then we'd need to check if the Stat64 API (90e2e8ada7c) was used by > the block tools, and if so also revert the atomic64 patches (around > 997d86a9bb1). If not some (sane) refactor is needed for some core > components (disentangle qdev from qom due to the atomic uses). Still > we rely heavily on atomic helpers for threads and co-routines used > by the block layer (and also to reference the QOM objects...). > > How / where would we test that (and for how long)?
IMHO we should not re-enable the block layer for 32-bit. Beyond the block/ directory, that also pulls in io/, crypto/, auth/, chardev/, and implies both unit testing and I/O tests too. I'd suggest we only make the guest agent work for 32-bit. aka this command line: ./configure --disable-system --disable-user --disable-tools --enable-guest-agent which limits us just to util/, qobject/, qapi/, qga/ dirs, and limited unit tests only. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
