Makefile.am | 4 1 + 3 - 0 !
configure.ac | 2 1 + 1 - 0 !
2 files changed, 2 insertions(+), 4 deletions(-)

 remove documentation from build system

The doc directory is removed from the source tarball by mk-origtargz, so
delete all reference to it in the build system.

src/read.c | 2 1 + 1 - 0 !
tests/scripts/targets/POSIX | 2 1 + 1 - 0 !
2 files changed, 2 insertions(+), 2 deletions(-)

 fix issues with ar operating in deterministic mode

It looks like the ar program in the binutils package in debian is now
configured with --enable-deterministic-archives. However, when dealing
with archive members, make needs the timestamp of the file in order to
decide to update it or not. With the current deterministic behavior of
ar, the timestamp is always 0. This change in ar introduced a behavior
that is not backward compatible and forces the use of the option U.

make fails to build, failing 7 out of 10 archive tests. Since make seems
to depend on timestamps to handle rebuilds of archives correctly, it
makes sense to always pass on the -U flag, and depend on a version of ar
that supports it.

Should this U option be included in a Makefile, older versions of ar
would reject it and fail.

There is some online discussion:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798804
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798913
https://bugzilla.redhat.com/show_bug.cgi?id=1195883

src/read.c | 6 3 + 3 - 0 !
1 file changed, 3 insertions(+), 3 deletions(-)

 fix ordering of include dirs

There has been a long standing bug where INCLUDE_DIRS /usr/include is
included twice. The more important problem is it is before the
/usr/local/include.

src/remake.c | 12 12 + 0 - 0 !
1 file changed, 12 insertions(+)

 fix directory search for link libraries

Bug fix: "make: Directory Search for Link Libraries does not look in
/usr/local/lib", thanks to Daniel Barlow. In the Debian binaries,
PREFIX is /usr and thus this searches /lib, /usr/lib and /usr/lib
again and therefore misses any libraries that are not packaged and
were installed by the site admin. The ideal behaviour would be to
have the search path set by a Makefile variable (other than the VPATH
blunt object) but even absent that, it would be more useful if it
looked in /usr/local/lib even though make itself hasn't been installed
in the /usr/local tree.

configure.ac | 2 1 + 1 - 0 !
src/job.c | 52 51 + 1 - 0 !
tests/scripts/features/long_command_line | 30 30 + 0 - 0 !
3 files changed, 82 insertions(+), 2 deletions(-)

 fix large command line on posix systems

When presented with a very long command line (as is common when linking
a large number of files with absolute paths in a deep subdirectory),
make fails to execute the command as it doesn't split the command line
to fit within the limits.

This is based on a fix for Debian bug 688601[1] by Adam Conrad applied
by Manoj Srivastava originally applied for Debian make-dfsg 4.0-5 in
2014 but dropped in 2018 (it seems under the incorrect assumption that
it had been accepted upstream.)

I've tweaked Adam's original patch so that it compiles successfully with
-Werror on top of current master. This required:

* moving the eval_line declaration to the top of the block, so I moved
  the macros too
* using a const variable when iterating over the shell
* adding a cast to avoid a signed/unsigned mismatch.

As suggested in the Savannah bug report[2], I've added a test case that
fails without the rest of the patch. I'm not sure what the consequences
of running the test on non-POSIX targets would be and whether it needs
marking as an expected failure.

* src/job.c (construct_command_argv_internal): support running commands
longer than MAX_ARG_STRLEN
* tests/scripts/features/long_command_line: add test for such a command
* configure.ac: check for now-required sys/user.h and linux/binfmts.h
headers

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688601
[2] https://savannah.gnu.org/bugs/?45763#comment2

Bug: https://savannah.gnu.org/bugs/?45763