On 8 August 2011 18:13, <david.hagood@xxxxxxxxx> wrote: > >> uintptr_t by definition is large enough to hold any pointer value, so >> casting from any pointer to uintptr_t should never give that warning. >> >> Are you sure your not using a target libc built for 32-bit and trying >> to use it for targetting 64-bit? That would explain why your target >> libc headers define a uintptr_t that is too small to hold a pointer >> value. > Absolutely sure. I built the target libc for biarch, and have 32 and 64 > bit versions in place in the sysroot directory. > > Also: once again, this all works if the target is PowerPC64. It *ONLY* > fails for X86_64 target. But the difference is that PPC64 defines > sizeof(int)=64 bits, while X86_64 defines sizeof(int)=32 bits. > > This looks like *somebody* is assuming that an int will always hold a > pointer - which is NOT guaranteed in the C standard (only a long is so > guaranteed). It's not guaranteed for long either, but it is guaranteed for uintptr_t, so if your libc is set up correctly then using uintptr_t should be ok. Why don't you look in the libc headers and see how it defines uintptr_t. In my native x86_64 system I see: /* Types for `void *' pointers. */ #if __WORDSIZE == 64 ... typedef unsigned long int uintptr_t; #else ... typedef unsigned int uintptr_t; #endif If your headers look sensible, figure out what is wrong when you compile libmudflap such that the wrong definition is used. Noone else has access to the files on your system so you're in the best position to investigate it.
