CVS compile on AIX 4.3.2
I am getting the following error
gmake[4]: Entering directory
`/usr/local/postgres/pgsql/src/backend/access/commo
n'
gcc -O2 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../../sr
c/include -I/usr/local/ssl/include -c -o printtup.o printtup.c
In file included from ../../../../src/include/libpq/libpq-be.h:22,
from ../../../../src/include/libpq/libpq.h:21,
from printtup.c:20:
../../../../src/include/libpq/pqcomm.h:60: `int64_t' undeclared here (not
in a f
unction)
../../../../src/include/libpq/pqcomm.h:64: parse error before "int64_t"
../../../../src/include/libpq/pqcomm.h:64: warning: no semicolon at end of
struc
t or union
../../../../src/include/libpq/pqcomm.h:67: `int64_t' undeclared here (not
in a f
unction)
../../../../src/include/libpq/pqcomm.h:67: `int64_t' undeclared here (not
in a f
unction)
../../../../src/include/libpq/pqcomm.h:71: parse error before '}' token
../../../../src/include/libpq/pqcomm.h:81: field `addr' has incomplete
type
gmake[4]: *** [printtup.o] Error 1
gmake[4]: Leaving directory
`/usr/local/postgres/pgsql/src/backend/access/common
'
gmake[3]: *** [common-recursive] Error 2
gmake[3]: Leaving directory `/usr/local/postgres/pgsql/src/backend/access'
gmake[2]: *** [access-recursive] Error 2
gmake[2]: Leaving directory `/usr/local/postgres/pgsql/src/backend'
horwitz@argoscomp.com (Samuel A Horwitz)
Samuel A Horwitz <horwitz@argoscomp.com> writes:
I am getting the following error
../../../../src/include/libpq/pqcomm.h:60: `int64_t' undeclared here (not
in a function)
There's a patch floating around the list to remove use of int64_t, which
is evidently not too portable. I'll try to get it applied soon.
regards, tom lane
I am getting the following error
../../../../src/include/libpq/pqcomm.h:60: `int64_t' undeclared here (not
in a function)There's a patch floating around the list to remove use of int64_t, which
is evidently not too portable. I'll try to get it applied soon.
int64_t is a C99 data type that hasn't existed prior to recent
versions of gcc, but is quite valid/correct. I'd think that int64_t
support should be fudged on platforms where in64_t isn't defined as
long long. IIRC, this is what FreeBSD has done for ages to get around
the lack of a 64bit type.
/* From machine/_types.h */
#if defined(lint)
/* LONGLONG */
typedef long long __int64_t;
/* LONGLONG */
typedef unsigned long long __uint64_t;
#elif defined(__GNUC__)
typedef int __attribute__((__mode__(__DI__))) __int64_t;
typedef unsigned int __attribute__((__mode__(__DI__))) __uint64_t;
#else
/* LONGLONG */
typedef long long __int64_t;
/* LONGLONG */
typedef unsigned long long __uint64_t;
#endif
-sc
--
Sean Chittenden
Sean Chittenden <sean@chittenden.org> writes:
int64_t is a C99 data type that hasn't existed prior to recent
versions of gcc, but is quite valid/correct. I'd think that int64_t
support should be fudged on platforms where in64_t isn't defined as
long long.
We have int64 defined (and well tested) already; I see no reason to muck
with it.
regards, tom lane
On Tue, 15 Jul 2003, Sean Chittenden wrote:
I am getting the following error
../../../../src/include/libpq/pqcomm.h:60: `int64_t' undeclared here (not
in a function)There's a patch floating around the list to remove use of int64_t, which
is evidently not too portable. I'll try to get it applied soon.int64_t is a C99 data type that hasn't existed prior to recent
versions of gcc, but is quite valid/correct. I'd think that int64_t
It's also not guaranteed to exist on any given machine if there isn't a
native exactly 64 bit integer type. I'd think that if you're going to use
one of the C99 integer types, int_least64_t or int_fast64_t would be a
better choice unless you really must guarantee 64 bits since those appear
to be required.