On 8 August 2011 14:26, <david.hagood@xxxxxxxxx> wrote:
> First: Thank you for taking the time to answer these questions. Not only
> am I hoping to solve MY problem, but I hope to help others who may have
> the same issues cross-compiling.
>
> I tried your suggestion about patching mf-runtime.c and that solved that
> issue, and that solved that problem, but I am running into another issue
> (see below).
>
>> 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?
>
> By "your libc" - do you mean the libc of the HOST/BUILD (in this case, 64
> bit SuSE) or the libc of the target (either X86_64 Linux or PowerPC
> Linux)? I'm assuming the second since the host libc obviously isn't
> changing. However, in the second case it's the same glibc source - only
> the target (or rather, "host" since libc is weird like that) changes.
>
> I wonder if the difference is in terms of how GCC models the targets:
> specifically the sizes of char/short int/int/long int - could it be
> sizeof(int) differs between GCC targeting PowerPC vs. GCC targeting
> X86_64?
>
> I wonder this because while the patch I tried against mf-runtime.c fixed
> that issue, I ran into another issue compiling GCC:
>
> In file included from /space/tools/ppc/src/gcc-4.6.1/libgomp/libgomp.h:50:0,
> from /space/tools/ppc/src/gcc-4.6.1/libgomp/alloc.c:29:
> /space/tools/ppc/src/gcc-4.6.1/libgomp/config/linux/ptrlock.h: In function
> ‘gomp_ptrlock_get’:
> /space/tools/ppc/src/gcc-4.6.1/libgomp/config/linux/ptrlock.h:42:7: error:
> cast from pointer to integer of different size
> [-Werror=pointer-to-int-cast]
>
> The offending code is:
> typedef void *gomp_ptrlock_t;
> ...
> static inline void *gomp_ptrlock_get (gomp_ptrlock_t *ptrlock)
> {
> if ((uintptr_t) *ptrlock > 2)
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.
