> get a chance. I don't have commit access, so Tom, shall I send a patch to
> you?
Send it to the patches list.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
On Mon, 7 Jul 2003 04:30 pm, Kurt Roeckx wrote:
> I used int64_t because that's standard (C99). But int64 will do
> too.
Okay... looks like it's only in a couple of places. I'll fix for Tru64 when I
get a chance. I don't have commit access, so Tom, shall I send a patch to
you?
Regards, Philip.
On Mon, Jul 07, 2003 at 01:46:21AM -0400, Tom Lane wrote:
> Philip Yarra <[EMAIL PROTECTED]> writes:
> > And on RedHat 7.3 it's in stdint.h - they must move it around to keep the
> > snipers guessing.
>
> Sometimes it seems that way :-(
>
> > What's the best (most portable) way to fix this?
>
>
Philip Yarra <[EMAIL PROTECTED]> writes:
> And on RedHat 7.3 it's in stdint.h - they must move it around to keep the
> snipers guessing.
Sometimes it seems that way :-(
> What's the best (most portable) way to fix this?
My vote is to rip out every last reference to int64_t and other
system-head
On Mon, 7 Jul 2003 03:09 pm, Joe Conway wrote:
> I found it on my Red Hat 9 box in sys/types.h:
>
> # if __GLIBC_HAVE_LONG_LONG
> __extension__ typedef long long int int64_t;
> # endif
And on RedHat 7.3 it's in stdint.h - they must move it around to keep the
snipers guessing.
If you haven't h
Philip Yarra wrote:
But then, it doesn't work on Linux (intel 32-bit) either... What's this
int64_t supposed to be? We're not just talking about a long long are we?
I found it on my Red Hat 9 box in sys/types.h:
# if __GLIBC_HAVE_LONG_LONG
__extension__ typedef long long int int64_t;
# endif
On Mon, 7 Jul 2003 02:53 pm, you wrote:
> Without some #include's, I'd expect it to fail, because int64_t isn't
> built into the C compiler. The question is exactly which #include
> are we missing.
Okay, got it: db.h
---(end of broadcast)---
T
Philip Yarra <[EMAIL PROTECTED]> writes:
> On Mon, 7 Jul 2003 02:19 pm, Tom Lane wrote:
>> Is type int64_t defined anywhere in your system headers? If so, where?
> Er... no... this:
> int main()
> {
> printf("sizeof is: %d\n", sizeof(int64_t));
> }
> fails with:
Without some #include's,
On Mon, 7 Jul 2003, Tom Lane wrote:
> Philip Yarra <[EMAIL PROTECTED]> writes:
> > I did a fresh CVS get (2003-07-07 12:30 UTC +10:00), attempted to build on
> > "OSF1 V4.0 1229 alpha" (Tru64 running on alpha) but build failed with:
>
> > In file included from ../../../../src/include/libpq/libpq-
On Mon, 7 Jul 2003 02:19 pm, Tom Lane wrote:
> Is type int64_t defined anywhere in your system headers? If so, where?
Er... no... this:
int main()
{
printf("sizeof is: %d\n", sizeof(int64_t));
}
fails with:
cc: Error: l.c, line 2: In this statement, "int64_t" is not declared.
(undecl
Philip Yarra <[EMAIL PROTECTED]> writes:
> I did a fresh CVS get (2003-07-07 12:30 UTC +10:00), attempted to build on
> "OSF1 V4.0 1229 alpha" (Tru64 running on alpha) but build failed with:
> In file included from ../../../../src/include/libpq/libpq-be.h:22,
> from ../../../../s
I did a fresh CVS get (2003-07-07 12:30 UTC +10:00), attempted to build on
"OSF1 V4.0 1229 alpha" (Tru64 running on alpha) but build failed with:
In file included from ../../../../src/include/libpq/libpq-be.h:22,
from ../../../../src/include/libpq/libpq.h:21,
fro
12 matches
Mail list logo
