With the glibc-kernheaders changes, xfsprogs stops building on ppc64. Adding an ExcludeArch temporarily: gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mminimal-toc -g -O2 -DNDEBUG -funsigned-char -fno-strict-aliasing -Wall -DVERSION=\"2.8.4\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I./include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -DNDEBUG -funsigned-char -fno-strict-aliasing -Wall -DVERSION=\"2.8.4\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -c -o xfs_copy.o xfs_copy.c In file included from /usr/include/asm/elf.h:5, from /usr/include/asm/sigcontext.h:12, from /usr/include/bits/sigcontext.h:28, from /usr/include/signal.h:333, from /usr/include/sys/wait.h:31, from xfs_copy.c:21: /usr/include/asm/types.h:40: error: conflicting types for '__s64' ../include/xfs/platform_defs.h:42: error: previous declaration of '__s64' was here /usr/include/asm/types.h:41: error: conflicting types for '__u64' ../include/xfs/platform_defs.h:41: error: previous declaration of '__u64' was here gmake[1]: *** [xfs_copy.o] Error 1
xfs should be using standard types (uint64_t) instead of defining its own copy of the kernel-private types.
Thanks Jeremy and David for looking into it. Guess one of you will fix and push it to the build system - can you add %{?dist} to the release tag of the xfsprogs then, too? Thank you (even if it's a bit off-topic here).
Jeff, ping on this? Would like to get this fixed for FC6 (and RHEL5)
The package glibc-kernheaders doesn't exist any longer. Does this problem also exist using the new kernel-headers package? I don't have access to a ppc64 system. BTW, bug #205906 is pointing to xfsprogs 2.8.11 which also could solve the problem.
You don't need a ppc64 system to know whether xfsprogs is still abusing the kernel types when it should be using proper types like uint64_t.
Can't we patch this (e.g. s/__u64/uint64_t/) and send the patch upstream?
That would be appropriate behaviour, yes.
I tested the latest xfsprogs-2.8.11 on a mostly-RHEL5-beta system with: kernel-headers-2.6.17-1.2519.4.21.el5.ppc64 kernel-headers-2.6.17-1.2519.4.21.el5.ppc glibc-headers-2.4.90-22.ppc and the problem persists. I pinged an sgi-guy about it, to see if they can get this fixed upstream.
Created attachment 137071 [details] xfsprogs-2.8.10-ppc64-types.patch I have opened some while ago an upstream bug here: http://oss.sgi.com/bugzilla/show_bug.cgi?id=707 I'll attach a patch that works for me. Though I don't programm that often and don't know if this is the propper fix...
Created attachment 137107 [details] xfsprogs-2.8.10-types.patch Just to let you know, here is the patch from upstream, which is definetly better.
It's still abusing kernel-private types and namespace. It should just switch to uint32_t et al -- proper C99 types.
Markus, could you please reopen the bug at SGI bugzilla, as it isn't really fixed?
Just checked the spec file to upgrade xfsprogs to the latest version 2.8.11. Included the ppc64 build patch. Passed all brew builds.