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:
parent
0a15090dba
commit
648f007fdb
|
@ -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
|
@ -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))
|
||||
|
||||
|
|
Loading…
Reference in New Issue