Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> To summarize:
> - Autoconf 2.71 has been out for 1.5 years.
> - It is available in many recently updated OSs.
> - It allows us to throw away several workarounds.
> Hence:
>> Currently, I think early PG16 might be good time to do this update.
In preparation for reviewing this, I tried to install autoconf 2.71
from source locally. All went well on my RHEL8 workstation, but
autoconf's testsuite falls over rather badly on my macOS laptop [1].
It fails differently on another Mac where I have a MacPorts
installation at the head of the search path [2].
After sending the requested reports, I tried scanning the bug-autoconf
archives, and found a similar report that was answered thus [3]:
> I *think* this is the same problem as https://savannah.gnu.org/support/?110492
> : current Autoconf doesn't work correctly with the (rather old) version of GNU
> M4 that ships with MacOS. Please try installing a current version of GNU M4 in
> your PATH and then retry the build and testsuite.
So that explains part of it: most of the failures are down to using
Apple's hoary m4 instead of the one from MacPorts. We could usefully
warn about that in our own docs, perhaps. But there's still these
scary failures:
509: AC_CHECK_HEADER_STDBOOL FAILED (acheaders.at:9)
514: AC_HEADER_STDBOOL FAILED (acheaders.at:14)
The generated autoconf program builds the same output files as you have
in your patch, and running the configure script gives the correct answer
from AC_HEADER_STDBOOL, so I'm not sure what these test failures are
unhappy about. Still, this is not a good look for a mainstream
development platform. I wonder if we ought to wait for a fix.
regards, tom lane
[1] https://lists.gnu.org/archive/html/bug-autoconf/2022-07/msg00000.html
[2] https://lists.gnu.org/archive/html/bug-autoconf/2022-07/msg00001.html
[3] https://lists.gnu.org/archive/html/bug-autoconf/2022-04/msg00002.html