emerge sys-fs/xfsprogs fails with: stat.c: In function 'dump_raw_statx': stat.c:354:56: error: 'struct statx' has no member named 'stx_atomic_write_unit_min' 354 | printf("stat.atomic_write_unit_min = %u\n", stx->stx_atomic_write_unit_min); | ^~ stat.c:355:56: error: 'struct statx' has no member named 'stx_atomic_write_unit_max' 355 | printf("stat.atomic_write_unit_max = %u\n", stx->stx_atomic_write_unit_max); | ^~ stat.c:356:60: error: 'struct statx' has no member named 'stx_atomic_write_segments_max' 356 | printf("stat.atomic_write_segments_max = %u\n", stx->stx_atomic_write_segments_max); | ^~ gmake[2]: *** [../include/buildrules:81: stat.o] Error 1 gmake[1]: *** [include/buildrules:36: io] Error 2 make: *** [Makefile:84: default] Error 2 * ERROR: sys-fs/xfsprogs-6.12.0::gentoo failed (compile phase): happens with amd64 and ppc64le, both musl-hardened. Reproducible: Always
Please always include the full build.log and emerge --info. Please also don't CC arch teams. This should have been fixed by: commit f2a52b2ccb6cc830dba6f0b6be422308a5adbf65 Author: Sam James <sam@gentoo.org> Date: Sun Jan 12 13:08:18 2025 +0000 sys-fs/xfsprogs: depend on >=sys-kernel/linux-headers-6.11 stx_atomic_write_unit_min was added in 0f9ca80fa4f9670ba09721e4e36b8baf086a500c in linux.git, first in linux-6.11. Bug: https://bugs.gentoo.org/947965 Signed-off-by: Sam James <sam@gentoo.org>
thanks for the quick reply but it didn't work. i ran emerge --sync in advance and installed sys-kernel/linux-headers again. # qlist -ICv | fgrep headers cross-powerpc64le-unknown-linux-musl/linux-headers-6.12 sys-kernel/linux-headers-6.12 emerge --info and build.log attached.
Created attachment 917187 [details] build.log
Created attachment 917188 [details] emerge_info
This can be worked around with -DOVERRIDE_SYSTEM_STATX in CFLAGS. The logic in check this will need some further investigation, the configure check are done with -D_GNU_SOURCE so sys/stat.h should have the statx struct defined, but it shouldnt have statx.stx_atomic_write_unit_min which still gets detected as available in the log. https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/diff/?h=v6.12.0&id=409477af604f465169be9b2cbe259fe382f052ae checking for struct statx... yes checking for struct statx.stx_atomic_write_unit_min... yes
Ok, so the logic is that the checks are done against linux/sys.h, BUT they dont get included in statx.h if STATX_TYPE is set (that musls sys/stat.h would set of course).
confirming, should we mask for musl profiles, or apply -DOVERRIDE_SYSTEM_STATX? 6.13.0-r1 has the same problem. Thanks to parona for the hint, this would be a possible fix using the define: --- a/sys-fs/xfsprogs/xfsprogs-6.12.0.ebuild +++ b/sys-fs/xfsprogs/xfsprogs-6.12.0.ebuild @@ -58,8 +58,8 @@ src_configure() { # Avoid automagic on libdevmapper (bug #709694) export ac_cv_search_dm_task_create=no - # bug 903611 - use elibc_musl && append-flags -D_LARGEFILE64_SOURCE + # bug 903611, 948468 + use elibc_musl && append-flags -D_LARGEFILE64_SOURCE -DOVERRIDE_SYSTEM_STATX # Build fails with -O3 (bug #712698) replace-flags -O3 -O2
Please apply -DOVERRIDE_SYSTEM_STATX, thanks!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=59746b5c334655b4de679bbf2406bc8e1bfade11 commit 59746b5c334655b4de679bbf2406bc8e1bfade11 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2025-03-14 07:38:26 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2025-03-14 07:40:28 +0000 sys-fs/xfsprogs-6.1{2,3}: fix compilation on musl systems #948468 Suggested-by: Alfred Wingate <parona@protonmail.com> Closes: https://bugs.gentoo.org/948468 Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-fs/xfsprogs/xfsprogs-6.12.0.ebuild | 5 +++-- sys-fs/xfsprogs/xfsprogs-6.13.0-r1.ebuild | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-)
downgrading -O3 is not necessary anymore.
(In reply to Goetz Fischer from comment #10) > downgrading -O3 is not necessary anymore. That's not related to this bug.
well, it's shown in the commit log above.
(In reply to Goetz Fischer from comment #12) > well, it's shown in the commit log above. No, it's just patch context.
