Re: [PATCH] Pacify GCC -Wsign-compare

2022-09-22 Thread Sam James
> On 22 Sep 2022, at 01:24, Paul Eggert wrote: > > On 9/21/22 16:11, Sam James wrote: >> For these, could you consider including the full version? > > Sure, revised patch attached.<0001-Pacify-GCC-Wsign-compare.patch> Thanks and looks good. signature.asc Description: Message signed with

Re: 4.3.90 release candidate segfault on Mac OS 12.6

2022-09-22 Thread John Graham-Cumming
$ ls -al total 608 drwxr-xr-x 4 jgc staff 128 22 Sep 20:58 . drwx--@ 14 jgc staff 448 22 Sep 20:58 .. -rw-r--r-- 1 jgc staff 24 22 Sep 20:58 Makefile -rwxr-xr-x 1 jgc staff 304384 22 Sep 20:58 make $ cat Makefile $(info $(wildcard foo)) $ ./make zsh: segmentation

Re: 4.3.90 release candidate segfault on Mac OS 12.6

2022-09-22 Thread Paul Smith
On Thu, 2022-09-22 at 20:34 +0100, John Graham-Cumming wrote: > Simply did ./configure. It’s an Intel Mac. Compiler seems to be > clang.  > > Doing a clean build shows a few warnings when compiling. Those are not a problem. In addition to answers to the questions I asked below, can you send the

Re: 4.3.90 release candidate segfault on Mac OS 12.6

2022-09-22 Thread John Graham-Cumming
Simply did ./configure. It’s an Intel Mac. Compiler seems to be clang. Doing a clean build shows a few warnings when compiling. On Thu, 22 Sep 2022 at 20:21, Paul Smith wrote: > On Thu, 2022-09-22 at 14:13 +0100, John Graham-Cumming wrote: > > $ sw_vers > > ProductName: macOS > >

Re: 4.3.90 release candidate segfault on Mac OS 12.6

2022-09-22 Thread Paul Smith
On Thu, 2022-09-22 at 14:13 +0100, John Graham-Cumming wrote: > $ sw_vers > ProductName: macOS > ProductVersion: 12.6 > BuildVersion: 21G115 > >  $ ./make -v > GNU Make 4.3.90 > > $ cat Makefile > $(info $(wildcard foo)) > > $ rm -f foo > $ ./make > zsh: segmentation fault  ./make Hm, I cannot

Re: Make 4.3.90 breaks makefile of dtc

2022-09-22 Thread Paul Smith
On Thu, 2022-09-22 at 10:54 +0200, Andreas Schwab wrote: > The issue is that the bison rule says it creates a %.output file, but > doesn't actually do that. > > %.tab.c %.tab.h %.output: %.y > @$(VECHO) BISON $@ > $(BISON) -b $(basename $(basename $@)) -d $< > > Note that no

Re: [PATCH] Port to 32-bit long + 64-bit time_t

2022-09-22 Thread Paul Eggert
On 9/21/22 23:49, Eli Zaretskii wrote: This will cause problems in the native MS-Windows builds, where printf in the system C runtime doesn't support %lld and %llu. Thanks for the review. Revised patch attached. It also addresses your comment about the commit message, plus it fixes a couple

Re: Make 4.3.90 breaks makefile of dtc

2022-09-22 Thread Dmitry Goncharov
On Thu, Sep 22, 2022 at 4:39 AM Andreas Schwab wrote: ... > Interestingly, this eventually runs out of file > descriptors, because, due to -O, make keeps opening new pipes for > synchronizing the output without closing any. Without -O, this would > probably go on forever. Make used to

4.3.90 release candidate segfault on Mac OS 12.6

2022-09-22 Thread John Graham-Cumming
$ sw_vers ProductName: macOS ProductVersion: 12.6 BuildVersion: 21G115 $ ./make -v GNU Make 4.3.90 Built for x86_64-apple-darwin21.6.0 Copyright (C) 1988-2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later < https://gnu.org/licenses/gpl.html> This is free software: you

Re: Make 4.3.90 breaks makefile of dtc

2022-09-22 Thread Andreas Schwab
The issue is that the bison rule says it creates a %.output file, but doesn't actually do that. %.tab.c %.tab.h %.output: %.y @$(VECHO) BISON $@ $(BISON) -b $(basename $(basename $@)) -d $< Note that no target actually depends on any *.output file. -- Andreas Schwab, SUSE Labs,

Make 4.3.90 breaks makefile of dtc

2022-09-22 Thread Andreas Schwab
>From >: set -e; echo ' CHK version_gen.h'; mkdir -p ./;(echo "#define DTC_VERSION \"DTC 1.6.1\""; ) < Makefile > version_gen.h.tmp; if [ -r version_gen.h ] && cmp -s version_gen.h

Re: [PATCH] Port to 32-bit long + 64-bit time_t

2022-09-22 Thread Eli Zaretskii
> Date: Wed, 21 Sep 2022 17:58:20 -0700 > Cc: bug-make@gnu.org > From: Paul Eggert > > On 9/20/22 18:48, rsbec...@nexbridge.com wrote: > > I am sorry to say that the %j prefix is not safe or portable. There are > > major production platforms where this is not supported. I work on one of > >