Build error 4.6.1 for x86_64

Jonathan Wakely
Mon Aug 8 17:44:00 GMT 2011

On 8 August 2011 18:13,  <> 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;
typedef unsigned int        uintptr_t;

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.

More information about the Gcc-help mailing list