| Thanks. I've got an updated version attached below, with the only
| additions that AC_OBJEXT is called before AC_EXEEXT in AC_PROG_CC,
| AC_PROG_CXX and AC_PROG_F77 (AC_EXEEXT uses $ac_objext).
Good!
| > I'd accept patches that do what you suggest too: have _AC_EXEEXT be
| > independent from AC_LINK_IFELSE, have AC_LINK|COMPILE_IFELSE require
| > what they need, [...]
|
| I looked at the code, but the macros that does the various compiler
| checks doesn't look "ready" for this change -- in particular, it looks
| hard to do the necessary changes without breaking the newly introduced
| AC_NO_EXECUTABLES hack.
:(
We will need to address all these issues in 2.51.
| So I'm afraid I'll leave that mess alone for now. :^/
I'll do the same. It works, that all we are asking for at the moment.
| 2000-08-30 Morten Eriksen <[EMAIL PROTECTED]>
|
| * acspecific.m4: _AC_OBJEXT was using AC_COMPILE_IFELSE, but
| AC_COMPILE_IFELSE depends on the value of $ac_objext. This
| dependency deadlock is broken by making _AC_OBJEXT independent
| of AC_COMPILE_IFELSE.
|
| * aclang.m4: _AC_EXEEXT depends on the value of $ac_objext, so
| run _AC_OBJEXT before _AC_EXEEXT. Also fixes a miniscule typo.
OK. But next time, please, write something like:
2000-08-30 Morten Eriksen <[EMAIL PROTECTED]>
* acspecific.m4 (_AC_OBJEXT): No longer use AC_COMPILE_IFELSE,
which uses $ac_objext hence depends upon _AC_OBJEXT.
* aclang.m4 (AC_PROG_CC, AC_PROG_CXX, AC_PROG_F77): Call
_AC_EXEEXT before _AC_OBJEXT since the former needs $ac_objext.
Akim
