Skip site navigation (1) Skip section navigation (2)

Re: Pg 7.2.3 int8 value out of range

From: Brian Macy <bmacy(at)macykids(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Pg 7.2.3 int8 value out of range
Date: 2002-10-18 17:41:09
Message-ID: 3DB047B5.60000@macykids.net (view raw or flat)
Thread:
Lists: pgsql-bugs
The config.log wasn't very useful but I hacked configure to not send 
compile/run errors to /dev/null and got this:

checking whether long long int is 64 bits... ./conftest: relocation 
error: ./conftest: undefined symbol: __muldi3

Apparrently something is whacked when running from configure. I can take 
the exact code (minus the confdefs.h) and run it from the command-line 
and it compiles, links, and executes fine (returns 0).


[] config.log:
configure:7610: checking whether long long int is 64 bits
configure:7648: gcc -o conftest -O2     conftest.c -lssl -lcrypto -lz 
-lcrypt -lresolv -lnsl -ldl -lm  1>&5
configure: failed program was:
#line 7619 "configure"
#include "confdefs.h"
typedef long long int int64;

/*
  * These are globals to discourage the compiler from folding all the
  * arithmetic tests down to compile-time constants.
  */
int64 a = 20000001;
int64 b = 40000005;

int does_int64_work()
{
   int64 c,d;

   if (sizeof(int64) != 8)
     return 0;                   /* definitely not the right size */

   /* Do perfunctory checks to see if 64-bit arithmetic seems to work */
   c = a * b;
   d = (c + b) / b;
   if (d != a+1)
     return 0;
   return 1;
}
main() {
   exit(! does_int64_work());
}


Tom Lane wrote:
> Brian Macy <bmacy(at)macykids(dot)net> writes:
> 
>>checking whether long int is 64 bits... no
>>checking whether long long int is 64 bits... no
> 
> 
> Well, that seems to be the problem.  Perhaps the relevant section of
> config.log would offer some hints?
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
> 


In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2002-10-18 18:59:55
Subject: Re: Pg 7.2.3 int8 value out of range
Previous:From: Tom LaneDate: 2002-10-18 14:02:08
Subject: Re: Bug #800: Bad free in function PQclear

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group