Peter Eisentraut <peter.eisentr...@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
