Re: GNU make 4.3.90 release candidate available: Compiler warnings on macOS
Am 20.09.22 um 20:36 schrieb Paul Smith: > A new release candidate for GNU make 4.4 is available now for download: > > 0c3daaec8c81bf72f460677ccda32364 make-4.3.90.tar.lz > 54726144a7ae0465451f8ca0740f3d1f make-4.3.90.tar.gz On macOS, compiling "glob.c" gives these warnings: glob.c:823:27: warning: incompatible pointer types passing 'char **' to parameter of type 'char *'; dereference with * [-Wincompatible-pointer-types] = (char **) realloc (pglob->gl_pathv, ^~~ * glob.c:942:24: warning: incompatible pointer types passing 'char **' to parameter of type 'char *'; dereference with * [-Wincompatible-pointer-types] = (char **) realloc (pglob->gl_pathv, ^~~ * glob.c:997:39: warning: incompatible pointer types passing 'char **' to parameter of type 'char *'; dereference with * [-Wincompatible-pointer-types] new_pathv = (char **) realloc (pglob->gl_pathv, ^~~ * glob.c:1388:23: warning: incompatible pointer types passing 'char **' to parameter of type 'char *'; dereference with * [-Wincompatible-pointer-types] = (char **) realloc (pglob->gl_pathv, ^~~ * but from what Paul said in https://lists.gnu.org/archive/html/bug-make/2019-05/msg00017.html > Argh, another glob.c issue. I really need to figure out how to update > to a newer version, preferably without breaking Windows AND pulling in > 75% of gnulib stuff in the process. I assume we still have to live with these warnings? Apart from that, there is only one compiler warning: src/getopt.c:685:6: warning: add explicit braces to avoid dangling else [-Wdangling-else] else ^ A fix had been posted in https://savannah.gnu.org/bugs/?func=detailitem_id=58075. That looks like a "small effort" change to me, perhaps it can be incorporated into GNU Make 4.4? Regards, Martin
Re: GNU make 4.3.90 release candidate available
> * Some POSIX systems (*BSD) do not allow locks to be taken on pipes, which > caused the output sync feature to not work properly there. Also multiple > invocations of make redirecting to the same output file (e.g., /dev/null) > would cause hangs. Instead of locking stdout (which does have some useful > performance characteristics, but is not portable) create a temporary file > and lock that. Windows continues to use a mutex as before. When make is interrupted (e.g. Ctrl+C), it fails to delete this temporary file. (I assume that's what /tmp/Gm* is.)
Re: GNU make 4.3.90 release candidate available
On Sun, 2022-10-02 at 22:14 +0200, Frank Heckenbach wrote: > I have a pattern rule like "%.c %.h &: %.y" for a tool (Bison) that > may generate two output files (.c and .h), but in some cases > (depending on the option "--defines") only one of them (.c). The change was intentional, but has been reverted--for now. See these Savannah bugs: https://savannah.gnu.org/bugs/index.php?12078 https://savannah.gnu.org/bugs/index.php?62098 https://savannah.gnu.org/bugs/index.php?63111 For GNU make 4.4 (unless more changes) this will work the way it used to work in GNU make 4.3, BUT you will get a warning saying that your recipe didn't create one of the files. The current intent is that in the next release after GNU make 4.4, the behavior will be switched back to GNU make 4.3.90. So you should probably prepare your makefiles appropriately.
Re: GNU make 4.3.90 release candidate available
I noticed a change in behaviour which I didn't find mentioned in (or an apparent consequence of) the listed backward-incompatible changes. I have a pattern rule like "%.c %.h &: %.y" for a tool (Bison) that may generate two output files (.c and .h), but in some cases (depending on the option "--defines") only one of them (.c). With previous make versions, this rule would work in both cases, even if no .h file was generated (or expected): % cat Makefile all: foo.c %.c %.h &: %.y; touch "$@" foo.y: ; touch "$@" clean: ; rm -f foo.y foo.c % make-4.3 touch "foo.y" touch "foo.c" % make-4.3 make-4.3: Nothing to be done for 'all'. With the new version, make keeps remaking foo.c because foo.h does not exist: % make clean rm -f foo.y foo.c % make touch "foo.y" touch "foo.c" % make touch "foo.c" % make touch "foo.c" Now, it's not a problem to me, I'll use something like "%.c $(if $(...),,%.h) &: %.y" (which is arguably more correct, anyway), just wanted to let you know in case this change in behaviour was not intended.
Re: GNU make 4.3.90 release candidate available
Thanks. For the record, my wget was from a Big Corporate network where I have no control over configuration. It's no problem for me to use --no-check-certificate, I'm just happy to hear the problem is not at the serving end. David On Mon, Sep 26, 2022 at 3:38 PM Martin Dorey < martin.do...@hitachivantara.com> wrote: > > It's more probable that David has outdated certificate DB and/or > > outdated GnuTLS on his machine. > > Thanks once again to Microsoft for obeying Dorey's Law of Marketing with > "safelinks", I only belatedly see David's evidence included "--2022-09-26 > 09:12:58--" which rather says that his clock wasn't messed up, contra my > earlier suggestion. > > martind@sirius:~$ < /dev/null openssl s_client -connect alpha.gnu.org:https > > /dev/null > depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 > verify return:1 > depth=1 C = US, O = Let's Encrypt, CN = R3 > verify return:1 > depth=0 CN = ftp.gnu.org > verify return:1 > DONE > martind@sirius:~$ > > "ISRG Root X1" rings a bell. Ah yes, it's that old chestnut: > https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/, > which contains advice for David. I also found the work around from > https://www.mail-archive.com/debian-lts@lists.debian.org/msg09627.html > specifically: > > sudo rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt > > ... to be helpful. > > -- > *From:* Bug-make on > behalf of Eli Zaretskii > *Sent:* Monday, September 26, 2022 10:10 > *To:* psm...@gnu.org > *Cc:* david.s.bo...@gmail.com ; bug-make@gnu.org > > *Subject:* Re: GNU make 4.3.90 release candidate available > > * EXTERNAL EMAIL * > > > From: Paul Smith > > Cc: bug-make@gnu.org > > Date: Mon, 26 Sep 2022 12:31:34 -0400 > > > > On Mon, 2022-09-26 at 12:16 -0400, David Boyce wrote: > > > BTW wget complains about the certificate: > > > > > > $ wget > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Falpha.gnu.org%2Fgnu%2Fmake%2Fmake-4.3.90.tar.gzdata=05%7C01%7CMartin.Dorey%40hitachivantara.com%7Cedd8aca6f47745c3454608da9fee5eb7%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C637998146567397614%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=LhGTvaG7H%2FEhlZTyhWwdwar%2Bxy2DdFbd1mMcNM1dGXI%3Dreserved=0 > > > --2022-09-26 09:12:58-- > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Falpha.gnu.org%2Fgnu%2Fmake%2Fmake-4.3.90.tar.gzdata=05%7C01%7CMartin.Dorey%40hitachivantara.com%7Cedd8aca6f47745c3454608da9fee5eb7%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C637998146567397614%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=LhGTvaG7H%2FEhlZTyhWwdwar%2Bxy2DdFbd1mMcNM1dGXI%3Dreserved=0 > > > Resolving alpha.gnu.org (alpha.gnu.org)... 209.51.188.21, > 2001:470:142:3::c > > > Connecting to alpha.gnu.org (alpha.gnu.org)|209.51.188.21|:443... > connected. > > > ERROR: cannot verify alpha.gnu.org's certificate, issued by > '/C=US/O=Let\'s Encrypt/CN=R3': > > > Issued certificate has expired. > > > To connect to alpha.gnu.org insecurely, use `--no-check-certificate'. > > > > Oddly I don't get this warning. Maybe I have somehow asked wget to not > > check expirations? > > It's more probable that David has outdated certificate DB and/or > outdated GnuTLS on his machine. > >
Re: GNU make 4.3.90 release candidate available
> It's more probable that David has outdated certificate DB and/or > outdated GnuTLS on his machine. Thanks once again to Microsoft for obeying Dorey's Law of Marketing with "safelinks", I only belatedly see David's evidence included "--2022-09-26 09:12:58--" which rather says that his clock wasn't messed up, contra my earlier suggestion. martind@sirius:~$ < /dev/null openssl s_client -connect alpha.gnu.org:https > /dev/null depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = ftp.gnu.org verify return:1 DONE martind@sirius:~$ "ISRG Root X1" rings a bell. Ah yes, it's that old chestnut: https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/, which contains advice for David. I also found the work around from https://www.mail-archive.com/debian-lts@lists.debian.org/msg09627.html specifically: sudo rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt ... to be helpful. From: Bug-make on behalf of Eli Zaretskii Sent: Monday, September 26, 2022 10:10 To: psm...@gnu.org Cc: david.s.bo...@gmail.com ; bug-make@gnu.org Subject: Re: GNU make 4.3.90 release candidate available * EXTERNAL EMAIL * > From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 26 Sep 2022 12:31:34 -0400 > > On Mon, 2022-09-26 at 12:16 -0400, David Boyce wrote: > > BTW wget complains about the certificate: > > > > $ wget > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Falpha.gnu.org%2Fgnu%2Fmake%2Fmake-4.3.90.tar.gzdata=05%7C01%7CMartin.Dorey%40hitachivantara.com%7Cedd8aca6f47745c3454608da9fee5eb7%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C637998146567397614%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=LhGTvaG7H%2FEhlZTyhWwdwar%2Bxy2DdFbd1mMcNM1dGXI%3Dreserved=0 > > --2022-09-26 09:12:58-- > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Falpha.gnu.org%2Fgnu%2Fmake%2Fmake-4.3.90.tar.gzdata=05%7C01%7CMartin.Dorey%40hitachivantara.com%7Cedd8aca6f47745c3454608da9fee5eb7%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C637998146567397614%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=LhGTvaG7H%2FEhlZTyhWwdwar%2Bxy2DdFbd1mMcNM1dGXI%3Dreserved=0 > > Resolving alpha.gnu.org (alpha.gnu.org)... 209.51.188.21, 2001:470:142:3::c > > Connecting to alpha.gnu.org (alpha.gnu.org)|209.51.188.21|:443... connected. > > ERROR: cannot verify alpha.gnu.org's certificate, issued by '/C=US/O=Let\'s > > Encrypt/CN=R3': > > Issued certificate has expired. > > To connect to alpha.gnu.org insecurely, use `--no-check-certificate'. > > Oddly I don't get this warning. Maybe I have somehow asked wget to not > check expirations? It's more probable that David has outdated certificate DB and/or outdated GnuTLS on his machine.
Re: GNU make 4.3.90 release candidate available
> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 26 Sep 2022 15:14:37 -0400 > > > Some binaries from Git for Windows are MinGW binaries, but some are > > MSYS2 binaries. All those for which Git Bash says they are in /bin > > (as opposed to /mingw64/bin) are MSYS2 binaries, they depend on MSYS > > DLL and don't use the Windows C runtime. MSYS2 is a fork of Cygwin, > > with a few subtle features that allow it to invoke native Windows > > programs without confusing them with Unix-style file names and PATH. > > To be honest I still don't think I understand all the intricacies of > this. All I know is that I add: > > set "PATH=%PATH%;C:\Strawberry\perl\bin;C:\Git\usr\bin" C:\Git\usr\bin holds MSYS2 executables, not MinGW executables. (MinGW executables that come with Git are in C:\Git\mingw64\bin.) So basically, you are running the tests in the MSYS2 environment, the only exclusion from that is make.exe itself.
Re: GNU make 4.3.90 release candidate available
On Mon, 2022-09-26 at 21:46 +0300, Eli Zaretskii wrote: > > On Mon, 2022-09-26 at 20:23 +0300, Eli Zaretskii wrote: > > > The following tests should be disabled on MS-Windows, because > > > they cannot possibly work: > > > > I have access to a VM running Windows 10 with a relatively recent > > Visual Studio install, with a recent Perl, and with the Git for > > Windows binaries (from MinGW I assume) on my PATH. No other cygwin > > or MinGW. > > Some binaries from Git for Windows are MinGW binaries, but some are > MSYS2 binaries. All those for which Git Bash says they are in /bin > (as opposed to /mingw64/bin) are MSYS2 binaries, they depend on MSYS > DLL and don't use the Windows C runtime. MSYS2 is a fork of Cygwin, > with a few subtle features that allow it to invoke native Windows > programs without confusing them with Unix-style file names and PATH. To be honest I still don't think I understand all the intricacies of this. All I know is that I add: set "PATH=%PATH%;C:\Strawberry\perl\bin;C:\Git\usr\bin" and everything "mostly works", with a relatively small number of things disabled in the test suite (on Windows I get 1083 tests passed in 124 categories, while on Linux it's 1213 tests passed in 134 categories). > > In this environment I can do this (in a Windows cmd.exe shell): > > > > tar xzf make-4.3.90.tar.gz > > cd make-4.3.90 > > .\build_w32.bat > > .\WinRel\gnumake.exe check > > > > This builds with Visual Studio and I get zero test failures. > > > > I assume a big part of this is that make is choosing bash as its > > shell, from the Git for Windows install, not cmd.exe. Plus other > > POSIX tools are available. > > Of course, it's because you set up Bash as the shell Make uses! Just to say, I didn't "set up Bash as the shell". I set my PATH as above, and ran the commands as above. If make is choosing to use bash it's because it was found on PATH, not because I made any explicit decision to choose it. > Which means many tests run in an environment that will rarely happen > in Real Life, when the native port of Make is used with cmd.exe as > the shell, not with MSYS2 Bash. I agree that using cmd.exe as make's shell would be a good thing to test, but IMO it's not actually all that rare for developers to have Git for Windows installed and on their PATH (including the usr/bin directory not just git.exe) these days, given how pervasive Git is. > The tests do need a few Unix tools (like 'sleep', 'cat', 'touch', and > maybe others), but those are available as native MinGW ports; whereas > Bash isn't. Moreover, when a Makefile uses the MSYS2 Bash, it will > generally invoke MSYS2 binaries of other tools, like 'cat' and > 'touch' (unless you are very careful to set up your PATH for Git > Bash). So you end up using "foreign" tools to run the tests, and I > find that less than optimal. (It is, of course, much less time- > consuming ;-) :). I usually run the tests on Windows before I push changes upstream, but I'm mainly just making sure I didn't break anything egregious and check that things basically compile and run, I'm not pretending that I'm doing any comprehensive testing. There are so many different environments to check on Windows and I don't understand how to install them, or even how to know which one I'm using. But, if it would be more helpful to not have C:\Git\usr\bin on my PATH during my basic tests I can remove it. > > > . 1 test in misc/bs-nl that uses single quotes around newlines > > > . 1 test in misc/general3 that uses single quotes around newlines > > > . 1 test in misc/general4 that unsets PATH (this cannot work on > > > Windows because Make will be unable to find the DLLs against which > > > it was linked, so it fails to start without valid PATH) > > > . targets/ONESHELL in its entirety (this feature doesn't work on > > > Windows) > > The last two should fail with MSYS Bash as well, I think. All I can say is that whatever tests are not currently marked to be omitted on Windows, work for me in the above environment. I just checked and for targets/ONESHELL I got 4 tests passed and for misc/general4 I got 10 tests passed.
Re: GNU make 4.3.90 release candidate available
> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 26 Sep 2022 14:23:40 -0400 > > On Mon, 2022-09-26 at 20:23 +0300, Eli Zaretskii wrote: > > The following tests should be disabled on MS-Windows, because they > > cannot possibly work: > > I have access to a VM running Windows 10 with a relatively recent > Visual Studio install, with a recent Perl, and with the Git for Windows > binaries (from MinGW I assume) on my PATH. No other cygwin or MinGW. Some binaries from Git for Windows are MinGW binaries, but some are MSYS2 binaries. All those for which Git Bash says they are in /bin (as opposed to /mingw64/bin) are MSYS2 binaries, they depend on MSYS DLL and don't use the Windows C runtime. MSYS2 is a fork of Cygwin, with a few subtle features that allow it to invoke native Windows programs without confusing them with Unix-style file names and PATH. > In this environment I can do this (in a Windows cmd.exe shell): > > tar xzf make-4.3.90.tar.gz > cd make-4.3.90 > .\build_w32.bat > .\WinRel\gnumake.exe check > > This builds with Visual Studio and I get zero test failures. > > I assume a big part of this is that make is choosing bash as its shell, > from the Git for Windows install, not cmd.exe. Plus other POSIX tools > are available. Of course, it's because you set up Bash as the shell Make uses! Which means many tests run in an environment that will rarely happen in Real Life, when the native port of Make is used with cmd.exe as the shell, not with MSYS2 Bash. The tests do need a few Unix tools (like 'sleep', 'cat', 'touch', and maybe others), but those are available as native MinGW ports; whereas Bash isn't. Moreover, when a Makefile uses the MSYS2 Bash, it will generally invoke MSYS2 binaries of other tools, like 'cat' and 'touch' (unless you are very careful to set up your PATH for Git Bash). So you end up using "foreign" tools to run the tests, and I find that less than optimal. (It is, of course, much less time-consuming ;-) > > . 1 test in misc/bs-nl that uses single quotes around newlines > > . 1 test in misc/general3 that uses single quotes around newlines > > . 1 test in misc/general4 that unsets PATH (this cannot work on > > Windows because Make will be unable to find the DLLs against which > > it was linked, so it fails to start without valid PATH) > > . targets/ONESHELL in its entirety (this feature doesn't work on > > Windows) > > I assume most/all of the above really mean, these tests won't work on > Windows when make uses a Windows shell such as cmd.exe. The last two should fail with MSYS Bash as well, I think. > Maybe we need to add a new check to the test framework that sets a > variable depending on what kind of shell make is using, then this > variable should be used when deciding which tests to run rather than > using "are we on Windows or not". Feel free, but what's the point of artificially making the tests "succeed" by forcing them to run in the MSYS environment? What does it gain us for testing the native MS-Windows port of Make? MSYS has its own port of GNU Make, one that uses largely the Posix code paths and bypasses the Windows-specific parts (for example, they use the job-server for parallelism). > > . targets/POSIX in its entirety > > The .POSIX: special target tells make that it should modify its > behavior to conform to the POSIX specification of make, in places where > it might differ by default. This happens on Windows the same as on > non-Windows. Yes, but look what is being tested there. I could, of course, tweak those tests to succeed on native Windows, but what's the point? E.g., this: # Test the default value of various POSIX-specific variables my %POSIX = (AR => 'ar', ARFLAGS => '-rv', YACC => 'yacc', YFLAGS => '', LEX => 'lex', LFLAGS => '', LDFLAGS => '', CC => 'c99', CFLAGS => '-O1', FC => 'fort77', FFLAGS => '-O1', SCCSFLAGS => '', SCCSGETFLAGS => '-s'); Does it really make sense to jump through hoops in order to test this on Windows?
Re: GNU make 4.3.90 release candidate available
On Mon, 2022-09-26 at 20:23 +0300, Eli Zaretskii wrote: > The following tests should be disabled on MS-Windows, because they > cannot possibly work: I have access to a VM running Windows 10 with a relatively recent Visual Studio install, with a recent Perl, and with the Git for Windows binaries (from MinGW I assume) on my PATH. No other cygwin or MinGW. In this environment I can do this (in a Windows cmd.exe shell): tar xzf make-4.3.90.tar.gz cd make-4.3.90 .\build_w32.bat .\WinRel\gnumake.exe check This builds with Visual Studio and I get zero test failures. I assume a big part of this is that make is choosing bash as its shell, from the Git for Windows install, not cmd.exe. Plus other POSIX tools are available. > . 1 test in misc/bs-nl that uses single quotes around newlines > . 1 test in misc/general3 that uses single quotes around newlines > . 1 test in misc/general4 that unsets PATH (this cannot work on > Windows because Make will be unable to find the DLLs against which > it was linked, so it fails to start without valid PATH) > . targets/ONESHELL in its entirety (this feature doesn't work on > Windows) I assume most/all of the above really mean, these tests won't work on Windows when make uses a Windows shell such as cmd.exe. Maybe we need to add a new check to the test framework that sets a variable depending on what kind of shell make is using, then this variable should be used when deciding which tests to run rather than using "are we on Windows or not". > . targets/POSIX in its entirety The .POSIX: special target tells make that it should modify its behavior to conform to the POSIX specification of make, in places where it might differ by default. This happens on Windows the same as on non-Windows. Some of those behaviors might require a real POSIX system to test but I'm not sure all of them do. I might be wrong though.
Re: GNU make 4.3.90 release candidate available
> From: Paul Smith > Cc: coordina...@translationproject.org > Date: Tue, 20 Sep 2022 14:36:05 -0400 > > A new release candidate for GNU make 4.4 is available now for download: > > 0c3daaec8c81bf72f460677ccda32364 make-4.3.90.tar.lz > 54726144a7ae0465451f8ca0740f3d1f make-4.3.90.tar.gz I've run the test suite on the MS-Windows build of this RC. All the tests that are expected to pass, do pass, after tweaking the scripts to heed to MS-Windows idiosyncrasies. The following tests should be disabled on MS-Windows, because they cannot possibly work: . 1 test in misc/bs-nl that uses single quotes around newlines . 1 test in misc/general3 that uses single quotes around newlines . 1 test in misc/general4 that unsets PATH (this cannot work on Windows because Make will be unable to find the DLLs against which it was linked, so it fails to start without valid PATH) . targets/ONESHELL in its entirety (this feature doesn't work on Windows) . targets/POSIX in its entirety
Re: GNU make 4.3.90 release candidate available
> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 26 Sep 2022 12:31:34 -0400 > > On Mon, 2022-09-26 at 12:16 -0400, David Boyce wrote: > > BTW wget complains about the certificate: > > > > $ wget https://alpha.gnu.org/gnu/make/make-4.3.90.tar.gz > > --2022-09-26 09:12:58-- https://alpha.gnu.org/gnu/make/make-4.3.90.tar.gz > > Resolving alpha.gnu.org (alpha.gnu.org)... 209.51.188.21, 2001:470:142:3::c > > Connecting to alpha.gnu.org (alpha.gnu.org)|209.51.188.21|:443... connected. > > ERROR: cannot verify alpha.gnu.org's certificate, issued by '/C=US/O=Let\'s > > Encrypt/CN=R3': > > Issued certificate has expired. > > To connect to alpha.gnu.org insecurely, use `--no-check-certificate'. > > Oddly I don't get this warning. Maybe I have somehow asked wget to not > check expirations? It's more probable that David has outdated certificate DB and/or outdated GnuTLS on his machine.
Re: GNU make 4.3.90 release candidate available
It doesn't look invalid to me: martind@sirius:~$ < /dev/null openssl s_client -connect alpha.gnu.org:https | openssl x509 -noout -text | grep Not depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = ftp.gnu.org verify return:1 DONE Not Before: Aug 16 01:14:49 2022 GMT Not After : Nov 14 01:14:48 2022 GMT martind@sirius:~$ Could David's clock be off by two months? From: Bug-make on behalf of Paul Smith Sent: Monday, September 26, 2022 09:31 To: David Boyce Cc: bug-make@gnu.org Subject: Re: GNU make 4.3.90 release candidate available * EXTERNAL EMAIL * On Mon, 2022-09-26 at 12:16 -0400, David Boyce wrote: > BTW wget complains about the certificate: > > $ wget > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Falpha.gnu.org%2Fgnu%2Fmake%2Fmake-4.3.90.tar.gzdata=05%7C01%7CMartin.Dorey%40hitachivantara.com%7Cd9d68fbac4e549e976f708da9fe0ebd1%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C637998090639078946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=E8nHn%2FX4DuD1QGfZovJOW6Jx16gTYP2bzl2yo%2FNCHcQ%3Dreserved=0 > --2022-09-26 09:12:58-- > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Falpha.gnu.org%2Fgnu%2Fmake%2Fmake-4.3.90.tar.gzdata=05%7C01%7CMartin.Dorey%40hitachivantara.com%7Cd9d68fbac4e549e976f708da9fe0ebd1%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C637998090639078946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=E8nHn%2FX4DuD1QGfZovJOW6Jx16gTYP2bzl2yo%2FNCHcQ%3Dreserved=0 > Resolving alpha.gnu.org (alpha.gnu.org)... 209.51.188.21, 2001:470:142:3::c > Connecting to alpha.gnu.org (alpha.gnu.org)|209.51.188.21|:443... connected. > ERROR: cannot verify alpha.gnu.org's certificate, issued by '/C=US/O=Let\'s > Encrypt/CN=R3': > Issued certificate has expired. > To connect to alpha.gnu.org insecurely, use `--no-check-certificate'. Oddly I don't get this warning. Maybe I have somehow asked wget to not check expirations? I'm not sure who to report that to. Maybe gnu-prog-discuss ?
Re: GNU make 4.3.90 release candidate available
On Mon, 2022-09-26 at 12:16 -0400, David Boyce wrote: > BTW wget complains about the certificate: > > $ wget https://alpha.gnu.org/gnu/make/make-4.3.90.tar.gz > --2022-09-26 09:12:58-- https://alpha.gnu.org/gnu/make/make-4.3.90.tar.gz > Resolving alpha.gnu.org (alpha.gnu.org)... 209.51.188.21, 2001:470:142:3::c > Connecting to alpha.gnu.org (alpha.gnu.org)|209.51.188.21|:443... connected. > ERROR: cannot verify alpha.gnu.org's certificate, issued by '/C=US/O=Let\'s > Encrypt/CN=R3': > Issued certificate has expired. > To connect to alpha.gnu.org insecurely, use `--no-check-certificate'. Oddly I don't get this warning. Maybe I have somehow asked wget to not check expirations? I'm not sure who to report that to. Maybe gnu-prog-discuss ?
Re: GNU make 4.3.90 release candidate available
BTW wget complains about the certificate: $ wget https://alpha.gnu.org/gnu/make/make-4.3.90.tar.gz --2022-09-26 09:12:58-- https://alpha.gnu.org/gnu/make/make-4.3.90.tar.gz Resolving alpha.gnu.org (alpha.gnu.org)... 209.51.188.21, 2001:470:142:3::c Connecting to alpha.gnu.org (alpha.gnu.org)|209.51.188.21|:443... connected. ERROR: cannot verify alpha.gnu.org's certificate, issued by '/C=US/O=Let\'s Encrypt/CN=R3': Issued certificate has expired. To connect to alpha.gnu.org insecurely, use `--no-check-certificate'. On Tue, Sep 20, 2022 at 7:18 PM Paul Smith wrote: > > GNU make is a tool which controls the generation of executables and > other non-source files of a program from the program's source files. > > You can learn more at: https://www.gnu.org/software/make/ > > > A new release candidate for GNU make 4.4 is available now for download: > > 0c3daaec8c81bf72f460677ccda32364 make-4.3.90.tar.lz > 54726144a7ae0465451f8ca0740f3d1f make-4.3.90.tar.gz > > You can obtain a copy from: https://alpha.gnu.org/gnu/make/ > > - NEWS > > Version 4.3.90 (20 Sep 2022) > > A complete list of bugs fixed in this version is available here: > > > https://sv.gnu.org/bugs/index.php?group=make_id=111_release_id=109=custom > > * WARNING: Backward-incompatibility! > Previously if --no-print-directory was seen anywhere in the environment > or > command line it would take precedence over any --print-directory. Now, > the > last setting of directory printing options seen will be used, so a > command > line such as "--no-print-directory -w" _will_ show directory entry/exits. > > * WARNING: Backward-incompatibility! > Previously the order in which makefiles were remade was not explicitly > stated, but it was (roughly) the inverse of the order in which they were > processed by make. In this release, the order in which makefiles are > rebuilt is the same order in which make processed them, and this is > defined > to be true in the GNU make manual. > > * WARNING: Backward-incompatibility! > Previously only simple (one-letter) options were added to the MAKEFLAGS > variable that was visible while parsing makefiles. Now, all options are > available in MAKEFLAGS. If you want to check MAKEFLAGS for a one-letter > option, expanding "$(firstword -$(MAKEFLAGS))" is a reliable way to > return > the set of one-letter options which can be examined via findstring, etc. > > * WARNING: Backward-incompatibility! > Previously makefile variables marked as export were not exported to > commands > started by the $(shell ...) function. Now, all exported variables are > exported to $(shell ...). If this leads to recursion during expansion, > then > for backward-compatibility the value from the original environment is > used. > To detect this change search for 'shell-export' in the .FEATURES > variable. > > * WARNING: New build requirement > GNU make utilizes facilities from GNU Gnulib: Gnulib requires certain C99 > features in the C compiler and so these features are required by GNU > make: > > https://www.gnu.org/software/gnulib/manual/html_node/C99-features-assumed.html > The configure script should verify the compiler has these features. > > * New feature: The .WAIT special target > If the .WAIT target appears between two prerequisites of a target, then > GNU make will wait for all of the targets to the left of .WAIT in the > list > to complete before starting any of the targets to the right of .WAIT. > This feature is available in some other versions of make, and it will be > required by an upcoming version of the POSIX standard for make. > Different patches were made by Alexey Neyman > (2005) > and Steffen Nurpmeso (2020) that were useful but > the > result is a different implementation (closer to Alexey's idea). > > * New feature: .NOTPARALLEL accepts prerequisites > If the .NOTPARALLEL special target has prerequisites then all > prerequisites > of those targets will be run serially (as if .WAIT was specified between > each prerequisite). > > * New feature: The .NOTINTERMEDIATE special target > .NOTINTERMEDIATE Disables intermediate behavior for specific files, for > all > files built using a pattern, or for the entire makefile. > Implementation provided by Dmitry Goncharov > > * New feature: The $(let ...) function > This function allows user-defined functions to define a set of local > variables: values can be assigned to these variables from within the > user-defined function and they will not impact global variable > assignments. > Implementation provided by Jouke Witteveen > > * New feature: The $(intcmp ...) function > This function allows conditional evaluation controlled by a numerical > comparison. >
Re: GNU make 4.3.90 release candidate available
> On 24 Sep 2022, at 18:45, Paul Smith wrote: > > On Wed, 2022-09-21 at 06:18 +0100, Sam James wrote: >> Can I suggest forwarding to the platform-testers@ mailing list as >> well? > > I've never heard of this; is it @gnu.org? Or somewhere else? A full > email address would be useful and also if you have any information on > this (a website or whatever) that would be good. > Eli beat me to explaining - sorry for being vague! You got it exactly, just platform-test...@gnu.org as a mailing list. > Cheers! > best, sam signature.asc Description: Message signed with OpenPGP
Re: GNU make 4.3.90 release candidate available
> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 25 Sep 2022 08:28:50 -0400 > > On Sun, 2022-09-25 at 13:30 +0300, Eli Zaretskii wrote: > > > From: Paul Smith > > > Cc: bug-make@gnu.org > > > Date: Sat, 24 Sep 2022 16:44:44 -0400 > > > > > > On Sat, 2022-09-24 at 16:41 -0400, Paul Smith wrote: > > > > makeint.h already has HAVE_MAKEINT_H > > > > > > Doh, I meant HAVE_INTTYPES_H of course. > > > > Is the below OK? > > Works for me. Thanks Eli. Thanks, installed together with the other 2 patches that avoid compilation warnings in the MS-Windows build.
Re: GNU make 4.3.90 release candidate available
On Sun, 2022-09-25 at 13:30 +0300, Eli Zaretskii wrote: > > From: Paul Smith > > Cc: bug-make@gnu.org > > Date: Sat, 24 Sep 2022 16:44:44 -0400 > > > > On Sat, 2022-09-24 at 16:41 -0400, Paul Smith wrote: > > > makeint.h already has HAVE_MAKEINT_H > > > > Doh, I meant HAVE_INTTYPES_H of course. > > Is the below OK? Works for me. Thanks Eli.
Re: GNU make 4.3.90 release candidate available
> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sat, 24 Sep 2022 16:44:44 -0400 > > On Sat, 2022-09-24 at 16:41 -0400, Paul Smith wrote: > > makeint.h already has HAVE_MAKEINT_H > > Doh, I meant HAVE_INTTYPES_H of course. Is the below OK? --- src/makeint.h~0 2022-09-18 22:06:17.0 +0300 +++ src/makeint.h 2022-09-25 13:24:52.53775 +0300 @@ -290,6 +290,14 @@ char *strerror (int errnum); #if HAVE_INTTYPES_H # include +#else +# ifndef PRId64 +# ifdef WINDOWS32 +# define PRId64 "I64d" +# else +# define PRId64 "lld" +# endif +# endif #endif #if HAVE_STDINT_H # include --- src/function.c~02022-09-18 22:06:17.0 +0300 +++ src/function.c 2022-09-25 13:26:45.88150 +0300 @@ -825,11 +825,11 @@ func_wordlist (char *o, char **argv, con if (start < 1) ON (fatal, *expanding_var, -"invalid first argument to 'wordlist' function: '%lld'", start); +"invalid first argument to 'wordlist' function: '%" PRId64 "'", start); if (stop < 0) ON (fatal, *expanding_var, -"invalid second argument to 'wordlist' function: '%lld'", stop); +"invalid second argument to 'wordlist' function: '%" PRId64 "'", stop); count = stop - start + 1;
Re: GNU make 4.3.90 release candidate available
On Sat, 2022-09-24 at 16:41 -0400, Paul Smith wrote: > makeint.h already has HAVE_MAKEINT_H Doh, I meant HAVE_INTTYPES_H of course.
Re: GNU make 4.3.90 release candidate available
On Sat, 2022-09-24 at 21:09 +0300, Eli Zaretskii wrote: > MinGW does have inttypes.h, if you want to use PRId64 or somesuch, > and > if the other supported platforms have that. > > I'm fine with using our own definition for PRId64, if that's what you > prefer. On makeint.h, I presume? makeint.h already has HAVE_MAKEINT_H and it's set by configure and all the custom config.h (or should be). So I guess afterward it would be something like, #ifndef PRId64 # ifdef WINDOWS32 # define PRId64 "I64d" # else # define PRId64 "lld" # endif #endif or something like that...?
Re: GNU make 4.3.90 release candidate available
> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sat, 24 Sep 2022 13:10:00 -0400 > > > Here are the proposed patches for the above 2 warnings. Paul, if you > > agree with them, I will install them in the repository. > > These changes look good to me, thanks! Thanks, installed.
Re: GNU make 4.3.90 release candidate available
> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sat, 24 Sep 2022 13:45:57 -0400 > > On Wed, 2022-09-21 at 06:18 +0100, Sam James wrote: > > Can I suggest forwarding to the platform-testers@ mailing list as > > well? > > I've never heard of this; is it @gnu.org? Yes, platform-test...@gnu.org.
Re: GNU make 4.3.90 release candidate available
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Sat, 24 Sep 2022 13:42:39 -0400
>
> On Sat, 2022-09-24 at 14:17 +0300, Eli Zaretskii wrote:
> > Here are the proposed patches:
> >
> > --- src/function.c~02022-09-18 22:06:17.0 +0300
> > +++ src/function.c 2022-09-24 13:30:01.740875000 +0300
> > @@ -823,6 +823,15 @@ func_wordlist (char *o, char **argv, con
> > stop = parse_numeric (argv[1],
> > _("invalid second argument to 'wordlist'
> > function"));
> >
> > +#ifdef WINDOWS32
> > + if (start < 1)
> > + ON (fatal, *expanding_var,
> > + "invalid first argument to 'wordlist' function: '%I64d'",
> > start);
> > +
> > + if (stop < 0)
> > + ON (fatal, *expanding_var,
> > + "invalid second argument to 'wordlist' function: '%I64d'",
> > stop);
> > +#else
> > if (start < 1)
> > ON (fatal, *expanding_var,
> > "invalid first argument to 'wordlist' function: '%lld'",
> > start);
> > @@ -830,6 +839,7 @@ func_wordlist (char *o, char **argv, con
> > if (stop < 0)
> > ON (fatal, *expanding_var,
> > "invalid second argument to 'wordlist' function: '%lld'",
> > stop);
> > +#endif
> >
> > count = stop - start + 1;
>
> I would prefer to avoid fully duplicating all the code, just to fix the
> string. I assume that the PR* macros are not portable?
MinGW does have inttypes.h, if you want to use PRId64 or somesuch, and
if the other supported platforms have that.
I'm fine with using our own definition for PRId64, if that's what you
prefer. On makeint.h, I presume?
Re: GNU make 4.3.90 release candidate available
On Wed, 2022-09-21 at 06:18 +0100, Sam James wrote: > Can I suggest forwarding to the platform-testers@ mailing list as > well? I've never heard of this; is it @gnu.org? Or somewhere else? A full email address would be useful and also if you have any information on this (a website or whatever) that would be good. Cheers!
Re: GNU make 4.3.90 release candidate available
On Sat, 2022-09-24 at 14:17 +0300, Eli Zaretskii wrote:
> Here are the proposed patches:
>
> --- src/function.c~02022-09-18 22:06:17.0 +0300
> +++ src/function.c 2022-09-24 13:30:01.740875000 +0300
> @@ -823,6 +823,15 @@ func_wordlist (char *o, char **argv, con
> stop = parse_numeric (argv[1],
> _("invalid second argument to 'wordlist'
> function"));
>
> +#ifdef WINDOWS32
> + if (start < 1)
> + ON (fatal, *expanding_var,
> + "invalid first argument to 'wordlist' function: '%I64d'",
> start);
> +
> + if (stop < 0)
> + ON (fatal, *expanding_var,
> + "invalid second argument to 'wordlist' function: '%I64d'",
> stop);
> +#else
> if (start < 1)
> ON (fatal, *expanding_var,
> "invalid first argument to 'wordlist' function: '%lld'",
> start);
> @@ -830,6 +839,7 @@ func_wordlist (char *o, char **argv, con
> if (stop < 0)
> ON (fatal, *expanding_var,
> "invalid second argument to 'wordlist' function: '%lld'",
> stop);
> +#endif
>
> count = stop - start + 1;
I would prefer to avoid fully duplicating all the code, just to fix the
string. I assume that the PR* macros are not portable? Maybe we can
create our own and use those?
> --- src/w32/pathstuff.c~0 2022-07-07 22:46:05.0 +0300
> +++ src/w32/pathstuff.c 2022-09-24 13:45:53.303375000 +0300
> @@ -102,11 +102,11 @@ w32ify(const char *filename, int resolve
> if (resolve)
> {
> char *fp = _fullpath (NULL, filename, sizeof (w32_path));
> - strncpy (w32_path, fp, sizeof (w32_path));
> + strncpy (w32_path, fp, sizeof (w32_path) - 1);
> free (fp);
> }
> else
> - strncpy(w32_path, filename, sizeof (w32_path));
> + strncpy(w32_path, filename, sizeof (w32_path) - 1);
>
> for (p = w32_path; p && *p; p++)
> if (*p == '\\')
>
>
> --- src/w32/w32os.c~0 2022-08-31 23:07:28.0 +0300
> +++ src/w32/w32os.c 2022-09-24 13:58:43.615875000 +0300
> @@ -22,7 +22,9 @@ this program. If not, see #include
> #include
> #include
> +#if _WIN32_WINNT > 0x0601
> #include
> +#endif
> #include "pathstuff.h"
> #include "sub_proc.h"
> #include "w32err.h"
> @@ -429,7 +431,7 @@ osync_get_mutex ()
> /* Prepare the mutex handle string for our children.
> 2 hex digits per byte + 2 characters for "0x" + null. */
> mutex = xmalloc ((2 * sizeof (osync_handle)) + 2 + 1);
> - sprintf (mutex, "0x%Ix", (unsigned long long)osync_handle);
> + sprintf (mutex, "0x%Ix", (unsigned long long)(DWORD_PTR)osync_handle);
> }
>
> return mutex;
> @@ -449,7 +451,7 @@ osync_parse_mutex (const char *mutex)
> if (endp[0] != '\0')
> OS (fatal, NILF, _("invalid output sync mutex: %s"), mutex);
>
> - osync_handle = (HANDLE) i;
> + osync_handle = (HANDLE) (DWORD_PTR) i;
>
> return 1;
> }
Weird, but OK.
Re: GNU make 4.3.90 release candidate available
On Sat, 2022-09-24 at 14:09 +0300, Eli Zaretskii wrote: > I've built this with mingw.org's MinGW for native MS-Windows. I > found several issues during the build, some of them specific to > Windows, others more general. (I didn't yet run the test suite, I > intend to do that next.) > > Here are the build-time issues that aren't specific to MS-Windows: > > src/getopt.c: In function '_getopt_internal': > src/getopt.c:679:8: warning: suggest explicit braces to avoid > ambiguous 'else' [-Wdangling-else] > 679 | if (opterr) > | ^ > > (This is not new to this release, I saw the same in Make 4.3.) I > ignored this one. Agreed. I need to update to the newer getopt library from gnulib (along with the newer glob library) but this is non-trivial for GNU make so I will probably wait until after this release. > Here are the proposed patches for the above 2 warnings. Paul, if you > agree with them, I will install them in the repository. These changes look good to me, thanks!
Re: GNU make 4.3.90 release candidate available
I've built this with mingw.org's MinGW for native MS-Windows. I found
several issues during the build, some of them specific to Windows,
others more general.
Below are the build-time issues that are specific to MS-Windows, and
the proposed patches. Paul, I'll wait for your okay before installing
those.
Warning in function.c:
In file included from src/function.c:17:
src/function.c: In function 'func_wordlist':
src/makeint.h:524:55: warning: unknown conversion type character 'l' in
format [-Wformat=]
524 | #define ON(_t,_a,_f,_n) _t((_a), INTSTR_LENGTH, (_f), (_n))
| ^~~~
src/function.c:827:5: note: in expansion of macro 'ON'
827 | ON (fatal, *expanding_var,
| ^~
src/makeint.h:524:55: warning: too many arguments for format
[-Wformat-extra-args]
524 | #define ON(_t,_a,_f,_n) _t((_a), INTSTR_LENGTH, (_f), (_n))
| ^~~~
src/function.c:827:5: note: in expansion of macro 'ON'
827 | ON (fatal, *expanding_var,
| ^~
src/makeint.h:524:55: warning: unknown conversion type character 'l' in
format [-Wformat=]
524 | #define ON(_t,_a,_f,_n) _t((_a), INTSTR_LENGTH, (_f), (_n))
| ^~~~
src/function.c:831:5: note: in expansion of macro 'ON'
831 | ON (fatal, *expanding_var,
| ^~
src/makeint.h:524:55: warning: too many arguments for format
[-Wformat-extra-args]
524 | #define ON(_t,_a,_f,_n) _t((_a), INTSTR_LENGTH, (_f), (_n))
| ^~~~
src/function.c:831:5: note: in expansion of macro 'ON'
831 | ON (fatal, *expanding_var,
| ^~
This is because %lld is not supported by MSVCRT.
Warnings in pathstuff.c:
src/w32/pathstuff.c: In function 'w32ify':
src/w32/pathstuff.c:109:7: warning: 'strncpy' specified bound 260 equals
destination size [-Wstringop-truncation]
109 | strncpy(w32_path, filename, sizeof (w32_path));
| ^~
src/w32/pathstuff.c:105:9: warning: 'strncpy' specified bound 260 equals
destination size [-Wstringop-truncation]
105 | strncpy (w32_path, fp, sizeof (w32_path));
| ^
I fixed those by copying 1 less characters.
Error in w32os.c:
src/w32/w32os.c:25:10: fatal error: synchapi.h: No such file or directory
25 | #include
| ^~~~
compilation terminated.
The MS documentation says to use synchapi.h only since Windows 8, so
this inclusion cannot be unconditional
Warning in w32os.c:
src/w32/w32os.c: In function 'osync_get_mutex':
src/w32/w32os.c:434:32: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
434 | sprintf (mutex, "0x%Ix", (unsigned long long)osync_handle);
|^
src/w32/w32os.c: In function 'osync_parse_mutex':
src/w32/w32os.c:454:18: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
454 | osync_handle = (HANDLE) i;
| ^
I fixed those by casting to DWORD_PTR first.
Here are the proposed patches:
--- src/function.c~02022-09-18 22:06:17.0 +0300
+++ src/function.c 2022-09-24 13:30:01.740875000 +0300
@@ -823,6 +823,15 @@ func_wordlist (char *o, char **argv, con
stop = parse_numeric (argv[1],
_("invalid second argument to 'wordlist' function"));
+#ifdef WINDOWS32
+ if (start < 1)
+ON (fatal, *expanding_var,
+"invalid first argument to 'wordlist' function: '%I64d'", start);
+
+ if (stop < 0)
+ON (fatal, *expanding_var,
+"invalid second argument to 'wordlist' function: '%I64d'", stop);
+#else
if (start < 1)
ON (fatal, *expanding_var,
"invalid first argument to 'wordlist' function: '%lld'", start);
@@ -830,6 +839,7 @@ func_wordlist (char *o, char **argv, con
if (stop < 0)
ON (fatal, *expanding_var,
"invalid second argument to 'wordlist' function: '%lld'", stop);
+#endif
count = stop - start + 1;
--- src/w32/pathstuff.c~0 2022-07-07 22:46:05.0 +0300
+++ src/w32/pathstuff.c 2022-09-24 13:45:53.303375000 +0300
@@ -102,11 +102,11 @@ w32ify(const char *filename, int resolve
if (resolve)
{
char *fp = _fullpath (NULL, filename, sizeof (w32_path));
-strncpy (w32_path, fp, sizeof (w32_path));
+strncpy (w32_path, fp, sizeof (w32_path) - 1);
free (fp);
}
else
- strncpy(w32_path, filename, sizeof (w32_path));
+ strncpy(w32_path, filename, sizeof (w32_path) - 1);
for (p = w32_path; p && *p;
Re: GNU make 4.3.90 release candidate available
I've built this with mingw.org's MinGW for native MS-Windows. I found
several issues during the build, some of them specific to Windows,
others more general. (I didn't yet run the test suite, I intend to do
that next.)
Here are the build-time issues that aren't specific to MS-Windows:
src/getopt.c: In function '_getopt_internal':
src/getopt.c:679:8: warning: suggest explicit braces to avoid ambiguous
'else' [-Wdangling-else]
679 | if (opterr)
|^
(This is not new to this release, I saw the same in Make 4.3.) I
ignored this one.
src/implicit.c: In function 'pattern_search':
src/implicit.c:237:9: warning: unused variable 'dend' [-Wunused-variable]
237 | char *dend = depname + deplen;
| ^~~~
This variable is only used in assertions; the proposed patch is below.
src/main.c: In function 'main':
src/main.c:2561:26: warning: variable 'len' set but not used
[-Wunused-but-set-variable]
2561 | size_t len;
| ^~~
Same here: the variable is only used in an assertion; the proposed
patch is below.
Here are the proposed patches for the above 2 warnings. Paul, if you
agree with them, I will install them in the repository.
--- src/implicit.c~02022-09-24 13:36:21.490875000 +0300
+++ src/implicit.c 2022-09-24 13:37:14.16275 +0300
@@ -234,7 +234,9 @@ pattern_search (struct file *file, int a
We may replace % by $(*F) for second expansion, increasing the length. */
size_t deplen = namelen + max_pattern_dep_length + 4;
char *depname = alloca (deplen);
+#ifndef NDEBUG
char *dend = depname + deplen;
+#endif
/* The start and length of the stem of FILENAME for the current rule. */
const char *stem = 0;
--- src/main.c~02022-09-20 10:55:39.0 +0300
+++ src/main.c 2022-09-24 13:40:33.584625000 +0300
@@ -2558,13 +2558,11 @@ main (int argc, char **argv, char **envp
for (; *av; ++av, ++nv)
{
- size_t len;
char *f;
char *a = *av;
const char *mf = makefiles->list[mfidx];
- len = strlen (a);
- assert (len > 0);
+ assert (strlen (a) > 0);
*nv = a;
Re: GNU make 4.3.90 release candidate available
> On 20 Sep 2022, at 19:36, Paul Smith wrote: > > >GNU make is a tool which controls the generation of executables and >other non-source files of a program from the program's source files. > >You can learn more at: https://www.gnu.org/software/make/ > > > A new release candidate for GNU make 4.4 is available now for download: Can I suggest forwarding to the platform-testers@ mailing list as well? Cheers! signature.asc Description: Message signed with OpenPGP
GNU make 4.3.90 release candidate available
GNU make is a tool which controls the generation of executables and other non-source files of a program from the program's source files. You can learn more at: https://www.gnu.org/software/make/ A new release candidate for GNU make 4.4 is available now for download: 0c3daaec8c81bf72f460677ccda32364 make-4.3.90.tar.lz 54726144a7ae0465451f8ca0740f3d1f make-4.3.90.tar.gz You can obtain a copy from: https://alpha.gnu.org/gnu/make/ - NEWS Version 4.3.90 (20 Sep 2022) A complete list of bugs fixed in this version is available here: https://sv.gnu.org/bugs/index.php?group=make_id=111_release_id=109=custom * WARNING: Backward-incompatibility! Previously if --no-print-directory was seen anywhere in the environment or command line it would take precedence over any --print-directory. Now, the last setting of directory printing options seen will be used, so a command line such as "--no-print-directory -w" _will_ show directory entry/exits. * WARNING: Backward-incompatibility! Previously the order in which makefiles were remade was not explicitly stated, but it was (roughly) the inverse of the order in which they were processed by make. In this release, the order in which makefiles are rebuilt is the same order in which make processed them, and this is defined to be true in the GNU make manual. * WARNING: Backward-incompatibility! Previously only simple (one-letter) options were added to the MAKEFLAGS variable that was visible while parsing makefiles. Now, all options are available in MAKEFLAGS. If you want to check MAKEFLAGS for a one-letter option, expanding "$(firstword -$(MAKEFLAGS))" is a reliable way to return the set of one-letter options which can be examined via findstring, etc. * WARNING: Backward-incompatibility! Previously makefile variables marked as export were not exported to commands started by the $(shell ...) function. Now, all exported variables are exported to $(shell ...). If this leads to recursion during expansion, then for backward-compatibility the value from the original environment is used. To detect this change search for 'shell-export' in the .FEATURES variable. * WARNING: New build requirement GNU make utilizes facilities from GNU Gnulib: Gnulib requires certain C99 features in the C compiler and so these features are required by GNU make: https://www.gnu.org/software/gnulib/manual/html_node/C99-features-assumed.html The configure script should verify the compiler has these features. * New feature: The .WAIT special target If the .WAIT target appears between two prerequisites of a target, then GNU make will wait for all of the targets to the left of .WAIT in the list to complete before starting any of the targets to the right of .WAIT. This feature is available in some other versions of make, and it will be required by an upcoming version of the POSIX standard for make. Different patches were made by Alexey Neyman (2005) and Steffen Nurpmeso (2020) that were useful but the result is a different implementation (closer to Alexey's idea). * New feature: .NOTPARALLEL accepts prerequisites If the .NOTPARALLEL special target has prerequisites then all prerequisites of those targets will be run serially (as if .WAIT was specified between each prerequisite). * New feature: The .NOTINTERMEDIATE special target .NOTINTERMEDIATE Disables intermediate behavior for specific files, for all files built using a pattern, or for the entire makefile. Implementation provided by Dmitry Goncharov * New feature: The $(let ...) function This function allows user-defined functions to define a set of local variables: values can be assigned to these variables from within the user-defined function and they will not impact global variable assignments. Implementation provided by Jouke Witteveen * New feature: The $(intcmp ...) function This function allows conditional evaluation controlled by a numerical comparison. Implementation provided by Jouke Witteveen * New feature: Improved support for -l / --load-average On systems that provide /proc/loadavg (Linux), GNU make will use it to determine the number of runnable jobs and use this as the current load, avoiding the need for heuristics. Implementation provided by Sven C. Dack * New feature: The --shuffle command line option This option reorders goals and prerequisites to simulate non-determinism that may be seen using parallel build. Shuffle mode allows a form of "fuzz testing" of parallel builds to verify that all prerequisites are correctly described in the makefile. Implementation provided by Sergei Trofimovich * New feature: The --jobserver-style command line option and named pipes A new
