+David for the VFIO thing On Tue, Aug 18, 2026, Hisam Mehboob wrote: > On 8/18/26 21:27, Sean Christopherson wrote: > > > Oh, so on top of "https://github.com/kvm-x86/linux.git next", this *is* the > > last > > blocker? If so, then I'll grab this for 7.3. > > Not quite -- I tested kvm-x86/next + this patch with musl-gcc, and the > build still fails. On top of the steal_time fix already in your tree, > two more musl blockers remain, both from code that is only in > kvm-x86/next so far: > > 1. hardware_disable_test.c, from 496779b54943 ("Pre-set threads affinity > in hardware disable test when possible"): > > hardware_disable_test.c:75: error: implicit declaration of function > 'pthread_attr_setaffinity_np' > > The call sits under #ifdef _GNU_SOURCE, but lib.mk defines _GNU_SOURCE > unconditionally, so the path is always taken and musl (which lacks the > function) breaks.
Heh, Sashiko flagged that as problematic, and I was trying to figure out which macro to key off of[*], but was (obviously) unsuccessful. I don't suppose you know the canonical way for checking for support of glibc-only functionality of this nature? [*] https://lore.kernel.org/all/[email protected] > > 2. The libvfio wiring from a262fc49e0aa ("Build and link > selftests/vfio/lib into KVM selftests"): > > vfio_pci_device.c:25: fatal error: uuid/uuid.h: No such file or > directory > sysfs.c:31: error: implicit declaration of function 'basename' > > The former adds a hard libuuid dependency (its headers aren't visible > to musl-gcc here); Can you elaborate on what you mean by "its headers aren't visible to musl-gcc"? > the latter because musl declares basename only in > <libgen.h>, while glibc exposes it via <string.h> under _GNU_SOURCE. IIUC, sysfs.c just needs to explicitly include libgen.h? > The rseq __GNUC_PREREQ failure is already covered by my patch in > linux-next. With the above sorted, the musl build passes.
