Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
0001-Remove-documentation-from-build-system.patch | 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. |
Manoj Srivastava <srivasta@debian.org> | not-needed | 2023-02-12 | ||
0002-Fix-issues-with-ar-operating-in-deterministic-mode.patch | 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 |
Manoj Srivastava <srivasta@debian.org> | no | 2023-02-12 | ||
0003-Fix-ordering-of-include-dirs.patch | 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. |
Manoj Srivastava <srivasta@debian.org> | no | 2023-02-12 | ||
0004-Fix-directory-search-for-link-libraries.patch | 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. |
Manoj Srivastava <srivasta@debian.org> | no | 2023-02-12 | ||
0005-Fix-large-command-line-on-POSIX-systems.patch | 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 |
Mike Crowe <mac@mcrowe.com> | yes | upstream | 2023-02-13 |