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: