I wrote:
> 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.
Hmm. I have just spent a very frustrating hour trying, and failing,
to build any version of GNU m4 from source on either RHEL8 or current
macOS. I don't quite understand why: neither the RPM specfile nor
the MacPorts recipe for their respective m4 packages seem to contain
any special hacks, so that it looks like the usual "configure; make;
make check; make install" procedure ought to work fine. But it doesn't.
I hit build failures (apparently because the source code is far too much
in bed with nonstandard aspects of libc), or get an executable that
SIGABRT's instantly, or if it doesn't do that it still fails some
self-tests. With the latest 1.4.19 on macOS, the configure script
hangs up, for crissakes.
I am now feeling *very* hesitant about doing anything where we might
be effectively asking people to build m4 for themselves.
On the whole, I'm questioning the value of messing with our autoconf
infrastructure at this stage. We did agree at PGCon that we'd keep
it going for a couple years more, but it's not real clear to me why
we can't limp along with 2.69 until we decide to drop it.
regards, tom lane
