Bugzilla – Bug 707
compile failure on PowerPC64 due to linux header problems
Last modified: 2007-06-14 02:34:07 CST
You need to log in before you can comment on or make changes to this bug.
Hello, since some version of xfsprogs > 2.7.3 (that version compiles fine) we are not able to compile xfsprogs any more on Linux/PowerPC64. The following output was copied from compiling xfsprogs 2.7.11: [...] === copy === gcc -g -DDEBUG -funsigned-char -fno-strict-aliasing -Wall -DVERSION=\"2.7.11\" -DLOCALEDIR=\"/usr/local/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:8, from /usr/include/asm/sigcontext.h:13, 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:44: error: conflicting types for ‘__s64’ ../include/xfs/platform_defs.h:42: error: previous declaration of ‘__s64’ was here /usr/include/asm/types.h:45: 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 make: *** [default] Error 2 As you can see definitions like __u64 are made in the linux kernel headers, but get redefined by xfsprogs. The solution would be to use POSIX names like uint64_t in xfsprogs, wouldn't it?
Ugh, how old is your glibc? This doesn't have problems on any other platform AFAIK, and its OK on Debian too, where I know theres an active PPC version. Any chance that a glibc upgrade fixes the problem for you? Its not so simple as just changing our types, cos we use copies of our XFS kernel headers in userspace, and we provide for them the types they need. It could be argued (and I will ;) that this is a libc bug for including kernel headers inappropriately... cheers.
I don't think I can upgrade glibc: $ /lib/libc.so.6 GNU C Library development release version 2.4, by Roland McGrath et al. [...] kernel headers are from kernel version 2.6.17. so you argue that types.h should not get included, or that there is something wrong in types.h (some missplaced/missing #ifdef __KERNEL__ or something like that)?
So this is the error message from xfsprogs-2.8.10: In file included from /usr/include/asm/elf.h:8, from /usr/include/asm/sigcontext.h:13, from /usr/include/bits/sigcontext.h:28, from /usr/include/signal.h:333, from /usr/include/aio.h:28, from lio.c:3: /usr/include/asm/types.h:44: error: conflicting types for '__s64' ../include/xfs/platform_defs.h:42: error: previous declaration of '__s64' was here /usr/include/asm/types.h:45: error: conflicting types for '__u64' ../include/xfs/platform_defs.h:41: error: previous declaration of '__u64' was here This happens because asm/sigcontext.h does only include asm/elf.h and so asm/elf.h if __powerpc64__ is defined (needed for elf_gregset_t/elf_fpregset_t).
RH has a bug on this too: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199315
Created an attachment (id=177) [details] xfsprogs-2.8.10-ppc64-types.patch hmm.. what about this patch? is it a correct fix?
Created an attachment (id=178) [details] xfsprogs sized int types patch The idea of this patch is to use the __u32 family of types from <asm/types.h> if they exist on the system using a configure test, otherwise define them ourselves. This change was added for xfsprogs-2.8.13. Can you tell me if this solves your problem or not? Need to remove the old configure script and do a make to create a new configure and have it run. If it doesn't fix it, then I'll need some other configure magic... I prefer to test for features using configure/autoconf than hardcoding test for platform macros if at all possible. Thanks muchly, --Tim
yes, that patch fixed it. thanks a lot! (In reply to comment #6) > This change was added for xfsprogs-2.8.13. Marking as FIXED then.
In version 2.8.21 the line "AC_CHECK_TYPES(__u32,,,[#include <asm/types.h>])" has been replaced with "AC_TYPE_U32", which brings the error back. HAVE___U32 is not being definded any more and so the #ifdef statement in include/platform_defs.h.in is not being evaluated correctly any more. Can you please change it back?
Created an attachment (id=223) [details] s/HAVE___U32_T/HAVE___U32/g I was defining the wrong macro.
(In reply to comment #8) > In version 2.8.21 the line "AC_CHECK_TYPES(__u32,,,[#include <asm/types.h>])" > has been replaced with "AC_TYPE_U32", which brings the error back. HAVE___U32 is > not being definded any more and so the #ifdef statement in > include/platform_defs.h.in is not being evaluated correctly any more. Can you > please change it back? Hi Markus, Sorry about the multitude of changes here. I was asked to change this, because apparently not everyone has an autoconf with AC_CHECK_TYPES IIRC. I was told to define a new macro for it in m4/package_types.m4. However, I botched up the change when creating AC_TYPE_U32. On the 1st of June (thanks to Eric Sandeen for pointing it out) I checked in the fix to xfsprogs. I'll attach the patch from this. Cheers, Tim.
thanks a lot. CVS version compiles and runs.