Copying conversation from bug-autoconf:

Frank Eigler:

> On the other hand, we've had very real reports that e.g. diff was
> missing on some real platforms, which led autoconf astray and ended up
> in misconfigured build trees.  Perhaps autoconf can afford to do some
> sanity checking on these reasonable-sounding but not-universal
> expectations.

Zack Weinberg:

> Frank, do you have details of those real platforms with missing diff?
> As I wrote in <https://savannah.gnu.org/support/index.php?111044>, it's
> difficult to implement this kind of sanity check without access to an
> environment that fails this kind of sanity check.  I could set one up
> myself but I wouldn't know if I had picked the right things to leave out.

Frank Eigler:

> Not a live system I use day-to-day.  But I mean I can remove
> "diffutils" from my Fedora box, and see it break.
>
> I think the point was not so much that normal & typical developer
> systems may fail.  It's that unforseen restricted machines (maybe
> running in minimal fashionably-"secure" buildroots) could encounter
> these problems, and then QUIETLY FAIL by misconfiguring tools.
>
> Thus the idea was just to do lightweight & obvious sanity checking on
> the environment at configure startup.  e.g.:
>
>    diff /dev/null /dev/null || exit 1

I think this gives me enough information to proceed.

Thank you for (re-)reporting this bug.  I agree that autoconf should make reasonable efforts to run in a minimal environment and, when the environment is too minimal to tolerate, it should give clear error messages.  In particular I agree that neither `diff` nor `awk` (and arguably not even `sed`) should be an implicit dependency.

That said, this kind of bug is very difficult to work on without concrete test cases and test environments.  If you could provide us with both of

• a minimized configure.ac that produces a configure script that malfunctions (meaning, neither runs to completion correctly nor produces a useful error message and halts) in the minimal environment you're working with

• details of the minimal environment you're working with, in particular the complete list of available shell commands ("command names" as defined in https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01 -- most importantly, both shell built-ins and external executables) and any cases where functionality guaranteed by POSIX.1-2001 is absent; f there is a straightforward recipe for constructing a matching environment from widely available free software, please describe it

that would be super helpful and would probably get the bug addressed orders of magnitude faster.

The script generated by autoconf may run in environments even sparser than the gnu standards.  One recentish example is missing "diff", which results in confusing diagnostics but not an outright failure.

It'd be helpful - and possibly improve security overall - if autoconf's generated shell script were to enumerate and assert the existence of every /usr/bin type basic utility its code relies on, and if absent, abort abort abort.  Better that than partial or obscured failures leading to oddly configured target programs.