Bug 2256836

The error is really weird. The failing part basically does following:

```
cc_supports_flag() {
    local CPPFLAGS="$@"
    AC_MSG_CHECKING([whether $CC supports "$@"])
    AC_PREPROC_IFELSE([AC_LANG_PROGRAM([])],
      [RC=0; AC_MSG_RESULT([yes])],
      [RC=1; AC_MSG_RESULT([no])])
}

cc_supports_flag "-Wall"
cc_supports_flag "-Wnonexisting-option"
```

So idea is to check if compiler supports flag, so it is fine (and expected) to pass unsupported option. We are using similar code in other projects (at least corosync/qdevice and booth) just using AC_COMPILE_IFELSE instead of AC_PREPROC_IFELSE and it is not failing.

So I've tried to create simplest configure.ac with following content:
```
AC_INIT([Hello], [1.0], [bug-hello])
AC_DEFINE([HELLO_WORLD], ["Hello, World\n"],
   [Greetings string.])
#AC_PROG_CC
#AC_PROG_CPP
cc_supports_flag() {
    local CPPFLAGS="$@"
    AC_MSG_CHECKING([whether $CC supports "$@"])
    AC_COMPILE_IFELSE([AC_LANG_PROGRAM([])],
      [RC=0; AC_MSG_RESULT([yes])],
      [RC=1; AC_MSG_RESULT([no])])
}

cc_supports_flag "-Wall"
cc_supports_flag "-Wnonexisting-option"
cc_supports_flag "-Wall"
```

and it was failing. BUT when AC_PROG_CC is uncommented, everything works as expected. Same works with AC_PREPROC_IFELSE if AC_PROG_CPP is uncommented. So I guess there was some change in autoconf which made AC_PROG_* required before AC_COMPILE_IFELSE/AC_PREPROC_IFELSE can be used as expected (no clue if it is bug or not, but calling AC_PROG_* is probably expected).

So conclusion (for resource-agents) is to add AC_PROG_CPP somewhere close to AC_PROG_CC and problem is solved.

There may have been some changes in indirect inclusion of AC_PROG_CPP, but that may also be an indirect side effect of how IFELSE has been re-emplemented (using `case..esac`).

It is required to have all needed AC_PROG* put explicitly in the configure.ac to ensure that all the necessary variable are made available in the global scope.
What may happen with 2.72 in your case, is that AC_PROG_CPP is indirectly added through AC_COMPILE_IFELSE which make the corresponding variables locally available, but these variables may get lost in later calls. Autoconf doesn't re-execute the associated code because it saves the fact that it has been done in the global scope. If AC_PROG_CPP gets called in a narrower scope, the associated variables may get lost.

That is also the reason why Autoconf recommends to use the IFELSE construct instead of direct shell constructs (if .. then.. fi), so that any variable created is ensured to be created in the proper scope.

Thank you for detailed explanation!

FEDORA-2024-6bc692c3c5 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-6bc692c3c5

FEDORA-2024-6bc692c3c5 has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.