Re: Solaris 10 x86 compile bug still there

Le jeudi 31 juillet 2008 à 01:51 -0500, Mike Brown a écrit :
> I reported this with pre2 and it is still there in pre3.
> 
> Solaris 10 x86
> AMD 6400+ X2 dual core
> 
> Compile error:
> 
> In file included from ../../thotlib/base/AmayaAppInstance.cpp:7:
> .../../thotlib/include/thot_sys.h:257: error: conflicting declaration 'typedef long int intptr_t'
> /usr/include/sys/int_types.h:104: error: 'intptr_t' has a previous declaration as `typedef int intptr_t'
> .../../thotlib/include/thot_sys.h:257: error: declaration of `typedef long int intptr_t'
> /usr/include/sys/int_types.h:104: error: conflicts with previous declaration `typedef int intptr_t'
> .../../thotlib/include/thot_sys.h:257: error: declaration of `typedef long int intptr_t'
> /usr/include/sys/int_types.h:104: error: conflicts with previous declaration `typedef int intptr_t'
> gmake[1]: *** [base/AmayaAppInstance.o] Error 1
> gmake[1]: Leaving directory `/usr/local/src/amaya-fullsrc-10.1-pre3/Amaya/Sol10/thotlib'
> gmake: *** [thotlib] Error 2
> 
> This is what is in the Solaris header file:
> 
> /*
>  * intptr_t and uintptr_t are signed and unsigned integer types large enough
>  * to hold any data pointer; that is, data pointers can be assigned into or
>  * from these integer types without losing precision.
>  */
> #if defined(_LP64) || defined(_I32LPx)
> typedef long                    intptr_t;
> typedef unsigned long           uintptr_t;
> #else
> typedef int                     intptr_t;
> typedef unsigned int            uintptr_t;
> #endif
> 
> This is what is in the Amaya source:
> 
> /* we encourage using "long" to store pointer values, never use "int" ! */
> #if !defined(__intptr_t_defined) && !defined(_INTPTR_T_DEFINED)
> #define __intptr_t_defined
> typedef           long   intptr_t;
> #endif
> 
> Any chance that this is going to get fixed soon?

I guess Solaris will move "long" pointer values like other platforms, so
I suggest you force -D_I32LPx when compiling amaya.
> 
> MB
-- 
Irene Vatton <Irene.Vatton@inria.fr>
INRIA

Received on Wednesday, 20 August 2008 09:29:05 UTC