You're precisely right:
From stdint.h:
/* There is some amount of overlap with <sys/types.h> as known by
inet code */
#ifndef __int8_t_defined
# define __int8_t_defined
typedef signed char int8_t;
typedef short int int16_t;
typedef int int32_t;
# if __WORDSIZE == 64
typedef long int int64_t;
# else
__extension__
typedef long long int int64_t;
# endif
#endif
From sys/types.h:
/* These types are defined by the ISO C99 header <inttypes.h>. */
# ifndef __int8_t_defined
# define __int8_t_defined
typedef char int8_t;
typedef short int int16_t;
typedef int int32_t;
# ifdef __GNUC__
__extension__ typedef long long int int64_t;
# endif
# endif
So unless you're __GNUC__ you don't get the int64_t. Is there a way
around this?
On Mar 15, 2006, at 4:34 PM, Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Wed, 15 Mar 2006 16:13 -0600:
On Wed, Mar 15, 2006 at 04:02:45PM -0600, Ti Leggett wrote:
I'll add to it that the exact same thing happens on ia64 as well.
int64_t is a c99 thing, which, being 2006, we didn't think was that
onerous a requirement!
Is there a special option for the intel compiler so that it will like
c99 constructs? The ICC on jazz says the flag '-std=c99' does the
trick. You might also try -c99 ?
Let me know if any of that worked and i'll add it to the faq.
That's funny because they're right there in glibc's
/usr/include/stdint.h but also in sys/types.h, C99 or no.
Maybe because adio.h picks up sys/types.h first, and it
conditionalizes int64_t on some glibc/gnuc defines. If
you can run "icc ... -E ad_fstype.c > ad_fstype.i" instead
of "icc ... -c ad_fstype.c", you can figure out why it's
skipping those int64_t typedefs.
-- Pete
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
