david.hagood@xxxxxxxxx writes: >> david.hagood@xxxxxxxxx writes: >> >>> /space/tools/ppc/src/gcc-4.6.1/libmudflap/mf-runtime.c:168:11: error: >>> conflicting types for ‘__mf_lc_mask’ >>> /space/tools/ppc/src/gcc-4.6.1/libmudflap/mf-runtime.h:46:23: note: >>> previous declaration of ‘__mf_lc_mask’ was here >> >> Looks like uintptr_t and __mf_uintptr_t are somehow different types. >> __mf_uintptr_t is defined via >> >> typedef unsigned int __mf_uintptr_t __attribute__ ((__mode__ >> (__pointer__))); >> >> uintptr_t is defined by some system header file. I would guess that the >> types normally wind up the same, but in the C library that you are using >> they somehow wind up being different. >> >> Probably mf-runtime.c should be changed to use __mf_uintptr_t rather >> than uintptr_t. >> >> Ian > Interesting. But why does this ONLY happen when building for X86_64, and > not for PPC? It's using the same host compiler - indeed, the only > difference is the --target option to the configure command ( and the > directory I am building in) - same source directory, same other options. It depends on your libc. The question is whether the uintptr_t define by your libc happens to match the __mf_uintptr_t type. So how does your libc define uintptr_t, and does it differ for x86_64 and PPC? Ian
