Re: [HACKERS] initdb problems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] initdb problems
Date: 1998-08-25 01:19:12
Message-ID: 26105.904007952@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
>> Firstly, configure.in seems to have reverted to it's original state
>> where the HAVE_LONG* stuff was broken.

> OK, I am not dealing with configure.in again on this int64 stuff. If
> someone wants to submit a patch to fix it, go ahead. No, "Just make it
> look like ...".

It's weird, I see the entries in "cvs log configure.in" saying that you
fixed it in updates 1.184 and 1.185, but there's no difference between
1.183 and 1.185:

$ cvs diff -r1.183 -r1.185 configure.in
Index: configure.in
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/configure.in,v
retrieving revision 1.183
retrieving revision 1.185
diff -r1.183 -r1.185
$

I hope this was just pilot error on your part, and not a symptom of
a cvs bug :-(

Anyway, here's a patch from the way that configure.in looks as of right
now, 1.185.

(It looks like the reason I messed up the int64 tests is that I copied
and pasted the HAVE_DBL_MIN_PROBLEM test, which was also broken...
fixed here.)

regards, tom lane

*** src/configure.in.orig Mon Aug 24 11:38:13 1998
--- src/configure.in Mon Aug 24 21:08:01 1998
***************
*** 522,528 ****
#endif
main() { double d = DBL_MIN; if (d != DBL_MIN) exit(-1); else exit(0); }],
AC_MSG_RESULT(yes),
! [AC_MSG_RESULT(no) AC_DEFINE(HAVE_DBL_MIN_PROBLEM)],
AC_MSG_RESULT(assuming ok on target machine))

dnl Check to see if we have a working 64-bit integer type.
--- 522,528 ----
#endif
main() { double d = DBL_MIN; if (d != DBL_MIN) exit(-1); else exit(0); }],
AC_MSG_RESULT(yes),
! [AC_DEFINE(HAVE_DBL_MIN_PROBLEM) AC_MSG_RESULT(no)],
AC_MSG_RESULT(assuming ok on target machine))

dnl Check to see if we have a working 64-bit integer type.
***************
*** 559,565 ****
main() {
exit(! does_int64_work());
}],
! [AC_MSG_RESULT(yes) AC_DEFINE(HAVE_LONG_INT_64)],
AC_MSG_RESULT(no),
AC_MSG_RESULT(assuming not on target machine))

--- 559,565 ----
main() {
exit(! does_int64_work());
}],
! [AC_DEFINE(HAVE_LONG_INT_64) AC_MSG_RESULT(yes)],
AC_MSG_RESULT(no),
AC_MSG_RESULT(assuming not on target machine))

***************
*** 596,602 ****
main() {
exit(! does_int64_work());
}],
! [AC_MSG_RESULT(yes) AC_DEFINE(HAVE_LONG_LONG_INT_64)],
AC_MSG_RESULT(no),
AC_MSG_RESULT(assuming not on target machine))

--- 596,602 ----
main() {
exit(! does_int64_work());
}],
! [AC_DEFINE(HAVE_LONG_LONG_INT_64) AC_MSG_RESULT(yes)],
AC_MSG_RESULT(no),
AC_MSG_RESULT(assuming not on target machine))

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1998-08-25 02:35:09 Re: [HACKERS] initdb problems
Previous Message Tom Lane 1998-08-25 01:01:18 Re: [HACKERS] Open 6.4 items