On Tue, Aug 18, 2026 at 2:03 PM Hisam Mehboob <[email protected]> wrote: > > On 8/19/26 00:28, Sean Christopherson wrote: > > +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] > > > > __GLIBC__ is the pragmatic in-tree answer. > _GNU_SOURCE is a request macro (input to the libc headers), not an > availability indicator -- lib.mk defines it unconditionally, so it > cannot detect anything. __USE_GNU works but is glibc-internal. > __GLIBC__ is defined by glibc's <features.h>, which any libc header > pulls in, and is the established idiom in selftests already: > kvm/lib/assert.c uses "#ifdef __GLIBC__" for execinfo.h, as do > bpf/test_progs.c and nolibc. musl deliberately provides no __MUSL__ -- > its FAQ's stance is "test for properties, don't assume them", which > strictly implies a compile test (autoconf-style); with no configure > step in selftests, __GLIBC__ is the established in-tree idiom. For > hardware_disable_test.c that is s/_GNU_SOURCE/__GLIBC__/ in the three > spots; build-tested with musl-gcc, passes. > > >> > >> 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"? > > musl-gcc searches only its own include directories > (here: /usr/include/x86_64-linux-musl and gcc's internal dir) and > deliberately not /usr/include, to avoid mixing glibc-oriented headers > with musl. uuid/uuid.h comes from libuuid (util-linux) and is installed > at /usr/include/uuid/uuid.h for the glibc toolchain, so glibc builds > find it and musl builds cannot. I see 2f0c30d0d1 already limits the > libvfio link to x86; the remaining gap on x86 is that libuuid is now a > hard dependency of the KVM selftests build (libvfio.mk adds -luuid), > and for musl-x86 the header is not visible at all without a > musl-targeted libuuid install. A uuid.h compile check to skip the vfio > pieces would keep it optional; otherwise the new dependency is probably > worth documenting.
libuuid is required to build libvfio, which VFIO and KVM selftests both depend on. How is this problem solved for other libraries, like -lpthread? > > > >> 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? > > Yes, adding <libgen.h> suffices. One nuance: there are two > flavors -- glibc under _GNU_SOURCE provides the GNU variant via > <string.h> (char *basename(const char *), non-modifying), while > <libgen.h> provides the POSIX variant (char *basename(char *), may > modify) and takes precedence on glibc as well. Safe at this call site: > rl_path is a writable buffer filled by readlink() (no trailing > slashes), used once by sscanf(). Verified with compile tests on both > libcs, and with <libgen.h> added, uuid/uuid.h is the only remaining > musl failure in the whole build. Feel free to send a patch, or I can if you prefer. > > >> The rseq __GNUC_PREREQ failure is already covered by my patch in > >> linux-next. With the above sorted, the musl build passes. >
