Thread: 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.