Re: [HACKERS] initdb problems - Mailing list pgsql-hackers
| From | Tom Lane |
|---|---|
| Subject | Re: [HACKERS] initdb problems |
| Date | |
| Msg-id | 26105.904007952@sss.pgh.pa.us Whole thread Raw |
| In response to | Re: [HACKERS] initdb problems (Bruce Momjian <maillist@candle.pha.pa.us>) |
| Responses |
Re: [HACKERS] initdb problems
|
| List | pgsql-hackers |
Bruce Momjian <maillist@candle.pha.pa.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))
pgsql-hackers by date: