Re: [GNU Autoconf 2.71] testsuite: 10 11 12 14 37 92 236 238 239 240 293 299 397 430 431 432 433 434 435 436 437 438 439 440 509 514 failed

[Tom Lane]

I wrote:
> After digging in the archives I see that most of those failures can
> be blamed on using Apple's ancient m4, and the tests on my other
> machine confirm that using MacPorts' m4 instead fixes them.

As penance for contributing noise, I thought I'd respond to the
question raised at [1] about which versions of m4 have this problem.

I soon found that GNU m4 is an incredibly fragile, system-dependent
mess.  A large fraction of my build attempts on different platforms
either failed to compile (because of ill-considered chumminess with
libc internals) or failed one or more "make check" tests.  I did
eventually find that I could build most versions on NetBSD 9.2/amd64,
and here's what I saw:

m4-1.4.7 shows largely the same set of failures as with 1.4.6:

   Subject: [GNU Autoconf 2.71] testsuite: 10 11 12 14 37 92 236 238 239 240 
260 269 293 299 397 430 431 432 433 434 435 436 437 438 439 440 594 failed

Note the addition of failures at 260, 269, 594, and the lack of failures
for 509 and 514; otherwise it's the same as my macOS/1.4.6 results.
It's believable that 509/514 are platform-specific to recent macOS,
while my results below make it look like 260/269 are NetBSD-specific.

With m4-1.4.8, there are just two failing tests:

   Subject: [GNU Autoconf 2.71] testsuite: 260 269 failed

I got the same with 1.4.9.  Skipping 1.4.10 and .11, I tried 1.4.12
(overriding configure's opinion that it doesn't work), and again
got just those two failures.  The same with 1.4.13, again overriding
configure.

m4 1.4.14 through .17 failed to build, because:

fseeko.c: In function 'rpl_fseeko':
fseeko.c:143:22: error: incompatible types when assigning to type '__off_t {aka 
long int}' from type 'fpos_t {aka struct __sfpos}'
         fp_->_offset = u.f;
                      ^

1.4.18 does build, and we're back to

   Subject: [GNU Autoconf 2.71] testsuite: 260 269 failed

1.4.19 builds but fails its own "make check", so this next result
maybe needs a grain of salt, but it looks fine to autoconf:

   Subject: [GNU Autoconf 2.71] testsuite: 260 269 failed

I didn't look into why those two tests failed across-the-board,
but it's presumably platform-specific.  (I do have the testsuite.log
files from all these runs, if anyone wants them.)

So as far as autoconf's test suite can tell, it appears that all m4
versions later than 1.4.7 are equally good.  They are not, however,
all equally easy to build on any given platform, and TBH it appears
to me that later versions are mostly worse not better on that score.

My recommendation would actually be to take out the check in m4.m4
that purports to reject buggy strstr behavior --- if that's looking
for something real, you couldn't tell it from the test suite.
I fear that what that might mostly accomplish is to keep people
from using the only m4 version that they can manage to build.
It'd be more useful to have a test suite entry that detects that,
so people can decide for themselves whether an autoconf that fails
one test out of 600 is acceptable or not.

                        regards, tom lane

[1] https://lists.gnu.org/archive/html/bug-autoconf/2022-04/msg00002.html