I have found a minor problem with current configure.in.

[AC_MSG_RESULT(yes) AC_DEFINE(HAVE_LONG_INT_64)],

this line produces something like:

  echo "$ac_t""yes" 1>&6 cat >> confdefs.h <<\EOF

and would append garbage "yes cat" to confdefs.h. Of course the
result confdefs.h is not syntactically correct therefore following
tests using confdefs.h would all fail.  To avoid the problem, we
could switch the order of AC_MSG_RESULT and AC_DEFINE (see attached
patch). This happend on my LinuxPPC box.


Tatsuo Ishii t-ishii@sra.co.jp
This commit is contained in:
Bruce Momjian 1998-08-24 04:09:39 +00:00
parent 0a15090dba
commit 648f007fdb
3 changed files with 528 additions and 525 deletions

View File

@ -76,7 +76,7 @@ _replace_var(Var *var)
lnext(vpe) = NULL;
}
for (i = 1;; i++)
for (i = ObjectIdAttributeNumber;; i++)
{
if (i == var->varattno)
break;

File diff suppressed because it is too large Load Diff

View File

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