Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On 4/19/24 15:15, Paul Smith wrote: On Fri, 2024-04-19 at 14:38 -0400, Dmitry Goncharov wrote: On Fri, Apr 19, 2024 at 1:42 PM Paul Smith wrote: The main advantages to alloca are twofold: 1) efficiency for small local buffers, which GNU Make uses a lot. 2) simplification of the code because

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On Fri, 2024-04-19 at 14:38 -0400, Dmitry Goncharov wrote: > On Fri, Apr 19, 2024 at 1:42 PM Paul Smith wrote: > > The main advantages to alloca are twofold: > > > > 1) efficiency for small local buffers, which GNU Make uses a lot. > > > > 2) simplification of the code because you don't have to

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On 4/19/24 14:38, Dmitry Goncharov wrote: On Fri, Apr 19, 2024 at 1:42 PM Paul Smith wrote: The main advantages to alloca are twofold: 1) efficiency for small local buffers, which GNU Make uses a lot. 2) simplification of the code because you don't have to track this memory and ensure it's fr

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On Fri, Apr 19, 2024 at 1:42 PM Paul Smith wrote: > The main advantages to alloca are twofold: > > 1) efficiency for small local buffers, which GNU Make uses a lot. > > 2) simplification of the code because you don't have to track this > memory and ensure it's freed regardless of how the function

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On Fri, 2024-04-19 at 13:15 -0400, Dennis Clarke wrote: > Yep. The calls to alloca() seem to be all over the place in the code > base and I can not figure out why anyone would want a non-portable > and non-standard thing like that but here we are. alloca() has been used in the GNU Make code ever s

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On 4/19/24 10:27, Paul Smith wrote: On Fri, 2024-04-19 at 09:54 -0400, Dennis Clarke via Bug reports and discussion for GNU make wrote: Where does one even begin to discover where something ( everything? ) went so horribly wrong? The very first thing you should try is re-configuring GNU Make w

Re: GNU Make 4.4.1 fails in a spectacular fashion on NetBSD 10.0 AMD64

On Fri, 2024-04-19 at 09:54 -0400, Dennis Clarke via Bug reports and discussion for GNU make wrote: > Where does one even begin to discover where something ( everything? ) > went so horribly wrong? The very first thing you should try is re-configuring GNU Make without any special flags (unset CFLA

Re: GNU make troubleshooting

On Sun, 2023-09-03 at 02:24 +0200, Alejandro Colomar wrote: > Let's add one more: > > -  Make has problems running the SHELL This is an interesting situation but I don't think it belongs in the GNU make manual. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org

Re: GNU make troubleshooting

Hi Paul, On 2023-08-26 18:48, Paul Smith wrote: > I added a new appendix to the GNU make manual for troubleshooting help; > I haven't pushed it yet. See below. Comments welcome. > > I think the outline you provided earlier, Bruno, has the problem that a > lot of it isn't really about troublesho

Re: GNU make troubleshooting

On Tue, 2023-08-29 at 09:44 -0400, David Boyce wrote: > - I find it interesting that there's no mention of -n which seems > like a bog-standard, POSIX-compliant, debugging method. It's also > another way of getting around @. Simplistic but worth mentioning > IMHO. I rarely use -n, personally. Als

Re: GNU make troubleshooting

A few thoughts, mostly on the shell/recipe end of things: - I find it interesting that there's no mention of -n which seems like a bog-standard, POSIX-compliant, debugging method. It's also another way of getting around @. Simplistic but worth mentioning IMHO. - I wonder why there's so much empha

Re: GNU make troubleshooting

Hi Paul, On 2023-08-27 15:52, Paul Smith wrote: > On Sun, 2023-08-27 at 15:47 +0200, Alejandro Colomar wrote: >> In fact, I'm going to define .SILENT always in the Linux man-pages, >> since V=1 is just an unnecessary duplicate for --degub=print. >> I'll make V=1 only have the effect of redirecting

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 15:47 +0200, Alejandro Colomar wrote: > In fact, I'm going to define .SILENT always in the Linux man-pages, > since V=1 is just an unnecessary duplicate for --degub=print. > I'll make V=1 only have the effect of redirecting stderr of certain > programs. Just be aware that --d

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 16:33 +0300, Eli Zaretskii wrote: > That error code 2 means file not found, and -1 means a command was > not found or completely failed to run.  It is easy to show a couple > of examples for each one, we see those every day. That might be true in Windows but it's not the case

Re: GNU make troubleshooting

On 2023-08-27 15:35, Alejandro Colomar wrote: > On 2023-08-27 15:33, Paul Smith wrote: >> On Sun, 2023-08-27 at 09:26 -0400, Paul Smith wrote: >>> Yes, that's a good idea to mention .SILENT. >> >> Actually I think I will simply recomment using --debug=print instead as >> that's simpler. > > LGTM.

Re: GNU make troubleshooting

On 2023-08-27 15:33, Paul Smith wrote: > On Sun, 2023-08-27 at 09:26 -0400, Paul Smith wrote: >> Yes, that's a good idea to mention .SILENT. > > Actually I think I will simply recomment using --debug=print instead as > that's simpler. LGTM. That's much better, as you don't modify the Makefile, a

Re: GNU make troubleshooting

> From: Paul Smith > Cc: br...@clisp.org, bug-make@gnu.org > Date: Sun, 27 Aug 2023 09:16:59 -0400 > > On Sun, 2023-08-27 at 08:51 +0300, Eli Zaretskii wrote: > > This checklist is very useful, but to make it even more useful, it > > lacks two things: > > > >  . an example of error message that

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 09:26 -0400, Paul Smith wrote: > Yes, that's a good idea to mention .SILENT. Actually I think I will simply recomment using --debug=print instead as that's simpler. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://mak

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 15:21 +0200, Alejandro Colomar wrote: > Maybe mention that removing .SILENT: would be necessary, if > it is defined.  Here's what the Linux man-pages makefiles do. Yes, that's a good idea to mention .SILENT. I really don't want to get into documenting all the different ways

Re: GNU make troubleshooting

Hi Paul, On 2023-08-27 15:16, Paul Smith wrote: > On Sun, 2023-08-27 at 08:51 +0300, Eli Zaretskii wrote:> >> Removing @ is not always enough. Many makefiles nowadays need you to >> say "make V=1" to override the default verbosity level. I suggest to >> mention that. > > What does "V=1" do, th

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 08:51 +0300, Eli Zaretskii wrote: > This checklist is very useful, but to make it even more useful, it > lacks two things: > >  . an example of error message that indicates each kind of problem >  . a cross-reference to where the details are There is a menu of links to each

Re: GNU make troubleshooting

Hi Paul, On 2023-08-26 18:48, Paul Smith wrote: > I added a new appendix to the GNU make manual for troubleshooting help; > I haven't pushed it yet. See below. Comments welcome. > > I think the outline you provided earlier, Bruno, has the problem that a > lot of it isn't really about troublesho

Re: GNU make troubleshooting

> From: Paul Smith > Date: Sat, 26 Aug 2023 12:48:05 -0400 > > I added a new appendix to the GNU make manual for troubleshooting help; > I haven't pushed it yet. See below. Comments welcome. Thanks, this sounds very useful. Some comments below. >If you have problems with GNU Make, first

Re: GNU make troubleshooting

I added a new appendix to the GNU make manual for troubleshooting help; I haven't pushed it yet. See below. Comments welcome. I think the outline you provided earlier, Bruno, has the problem that a lot of it isn't really about troubleshooting per se, it's about how to write makefiles in general.

Re: GNU make troubleshooting

Dmitry Goncharov wrote: > > I believe these two user goals are so different; they belong in different > > chapters. > ... > In other words, i don't see a chapter on how to avoid big debug output > without optimizing the makefile. Wait a second. "How to avoid big debug output?" is not one of the pr

Re: GNU make troubleshooting

On Sat, 2023-07-15 at 11:28 -0400, Dmitry Goncharov wrote: > Appendix A Debug Output. Thanks for this Dmitry; I spent some time this weekend working on a new section of the manual that would overlap with this. However I will definitely examine your patch and make sure the points you (and everyone

Re: GNU make troubleshooting

On 2023-07-16 22:14, Philip Guenther wrote: > I just put this at the very end of top makefile: > > ${MAKEFILE_LIST}: ; Hmm, that's giving me another good idea. Luckily, I haven't pushed the changes I had done yet. Thanks! Alex > > Philip Guenther -- GPG ke

Re: GNU make troubleshooting

I just put this at the very end of top makefile: ${MAKEFILE_LIST}: ; Philip Guenther On Sun, Jul 16, 2023 at 12:25 PM Torbjorn SVENSSON < torbjorn.svens...@foss.st.com> wrote: > > > On 2023-07-16 15:58, Alejandro Colomar wrote: > > Wow! That's a great help for debugging the Linux man-pages's m

Re: GNU make troubleshooting

On 2023-07-16 15:58, Alejandro Colomar wrote: Wow! That's a great help for debugging the Linux man-pages's makefiles, which don't need to be remade. It was very painful to me to ignore so much make -d output. I applied the following patch, and it works like a charm.

Re: GNU make troubleshooting

Como estas, Alex? On Sun, Jul 16, 2023 at 9:59 AM Alejandro Colomar wrote: > I applied the following patch > Glad you liked it. Rather than `find -type f...` (which is painfully slo

Re: GNU make troubleshooting

Hi Dmitry! On 2023-07-15 17:28, Dmitry Goncharov wrote: [...] > > $ make -d |tail +7 |head > Reading makefiles... > Reading makefile 'makefile'... > Updating makefiles > Considering target file 'makefile'. > Looking for an implicit rule for 'makefile'. >Trying pattern rule '%: %.o' wi

Re: GNU make troubleshooting

On Sat, Jul 15, 2023 at 5:27 PM Bruno Haible wrote: > I believe these two user goals are so different; they belong in different > chapters. i believe, a good approach to big debug output is to modify the makefile to relieve make from doing redundant work. Once make only does necessary minimal work

Re: GNU make troubleshooting

Minor side point: the "tail +7" option is deprecated by POSIX, replaced by "tail -n+7". Official GNU documentation should preferably follow POSIX. David On Sat, Jul 15, 2023 at 5:27 PM Bruno Haible wrote: > Dmitry Goncharov wrote: > > > 1) The title, and what does the user want? > > This patch

Re: GNU make troubleshooting

Dmitry Goncharov wrote: > > 1) The title, and what does the user want? > This patch is not a full-fledged troubleshooting guide. ... > > Is that really what I want to do and should do, as a user? > i believe, makefile authors should apply these techniques. OK, then it's appropriate to create *thre

Re: GNU make troubleshooting

> 1) The title, and what does the user want? i guess, users want make to do the minimal amount of work required to fulfil its duties correctly (e.g. track all dependencies, rebuilds, etc). This patch is not a full-fledged troubleshooting guide. This patch describes how to minimize the work that mak

Re: GNU make troubleshooting

Hello Dmitry, Dmitry Goncharov wrote: > >I tried -d a couple of times, and it produced a ton of output, that > >was too much for me to make sense of. Probably 10% to 20% of the > >developers in general have trace filtering skills, that is, know how > >to extract the essential infor

Re: GNU make troubleshooting

On Mon, Jul 10, 2023 at 2:32 PM Bruno Haible wrote: >I tried -d a couple of times, and it produced a ton of output, that >was too much for me to make sense of. Probably 10% to 20% of the >developers in general have trace filtering skills, that is, know how >to extract the essential

Re: GNU make troubleshooting

On Tue, 2023-07-11 at 10:01 -0400, Jeffrey Walton wrote: > > But, what about this do you want to know? > > I want to see an output for the evaluation of each statement, like > what I would see with 'set -x'. I need to know where something goes > sideways when shell'ing out in a pipe. If what you

Re: GNU make troubleshooting

Hi Jeff, On 2023-07-11 16:01, Jeffrey Walton wrote: >> But, what about this do you want to know? > > I want to see an output for the evaluation of each statement, like > what I would see with 'set -x'. I need to know where something goes > sideways when shell'ing out in a pipe. Could you show an

Re: GNU make troubleshooting

On Tue, Jul 11, 2023 at 9:44 AM Paul Smith wrote: > > On Mon, 2023-07-10 at 17:17 -0400, Jeffrey Walton wrote: > > Yes, lots of conditionals and lots of shell'ing, like: > > > > GREP ?= grep > > SED ?= sed > > > > ifneq ($(wildcard /usr/xpg4/bin/grep),) > > GREP := /usr/xpg4/bin/grep > > endif >

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 17:17 -0400, Jeffrey Walton wrote: > Yes, lots of conditionals and lots of shell'ing, like: > > GREP ?= grep > SED ?= sed > > ifneq ($(wildcard /usr/xpg4/bin/grep),) >   GREP := /usr/xpg4/bin/grep > endif > ifneq ($(wildcard /usr/xpg4/bin/sed),) >   SED := /usr/xpg4/bin/sed

Re: GNU make troubleshooting

> From: Bruno Haible > Date: Mon, 10 Jul 2023 21:41:24 +0200 > > Paul Smith wrote: > > Showing the "macroexpanded make sources" is difficult because make > > doesn't just expand an entire line then parse it. Makefile syntax is > > context-sensitive so you can't know how or if to expand parts of

Re: GNU make troubleshooting

> From: Jeffrey Walton > Date: Mon, 10 Jul 2023 16:34:49 -0400 > Cc: bug-make@gnu.org > > I would add GNU's make lacks minimal debug facilities. I think "make -p" and "make -d" do provide ample debugging capabilities. > I think trace is worthless. It does not help the folks writing > makefiles.

Re: GNU make troubleshooting

On Mon, Jul 10, 2023 at 4:45 PM Paul Smith wrote: > > [...] > > That's like peppering a program with printf's. I would like to > > understand why a statement was (or was not) evaluated, and if > > evaluated the result, but there is no option with the effect of > > Bash's 'set +x'. > > I think I do

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 16:34 -0400, Jeffrey Walton wrote: > I would add GNU's make lacks minimal debug facilities. I assume this is what Bruno means by his point #3: "Single-stepping or tracing function execution". > That's like peppering a program with printf's. I would like to > understand why a

Re: GNU make troubleshooting

Alejandro Colomar wrote: > In GNU Make, the "printf" statement is the > $(info ...) function. Maybe you didn't know about it? Correct, I did not know about it. I created a 'dummy' target with an echo command... It would be really useful to collect all these various troubleshooting tricks in a ch

Re: GNU make troubleshooting

On Mon, Jul 10, 2023 at 2:32 PM Bruno Haible wrote: > > In recent build system discussions on gnu-prog-discuss, the suggestion was > made [1] to use GNU make's power instead of autoconf, automake, and POSIX > make. > > I think GNU make is lacking transparency / debuggability / serviceability > fe

Re: GNU make troubleshooting

Hi Bruno, Paul, On 7/10/23 21:41, Bruno Haible wrote: Paul Smith wrote: Showing the "macroexpanded make sources" is difficult because make doesn't just expand an entire line then parse it. Makefile syntax is context-sensitive so you can't know how or if to expand parts of a line until you've a

Re: GNU make troubleshooting

Paul Smith wrote: > > I get the same output with GNU make 4.4 as with 4.3. > > Apologies for my mistake: I'm using the latest release (4.4.1). > I tried your test: > > $ make --trace mbrtoc32.o > Makefile:1752: update target 'mbrtoc32.o' due to: target does not exist With 4.4.1, I see this t

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:41 +0200, Bruno Haible wrote: > > I'm not interested in implementing an "interactive" mode for > > single-stepping GNU Make.  Maybe someone else wants to do it but my > > suspicion is that the code changes needed would be massively > > disruptive. > > That sounds like a di

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:47 +0200, Bruno Haible wrote: > Paul Smith wrote: > > Maybe a version difference.  I'm using 4.4. > > I get the same output with GNU make 4.4 as with 4.3. Apologies for my mistake: I'm using the latest release (4.4.1). I tried your test: $ make --trace mbrtoc32.o Mak

Re: GNU make troubleshooting

Paul Smith wrote: > Maybe a version difference. I'm using 4.4. I get the same output with GNU make 4.4 as with 4.3. Bruno

Re: GNU make troubleshooting

Paul Smith wrote: > Showing the "macroexpanded make sources" is difficult because make > doesn't just expand an entire line then parse it. Makefile syntax is > context-sensitive so you can't know how or if to expand parts of a line > until you've already expanded other parts. Of course make could

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:18 +0200, Bruno Haible wrote: > Paul Smith wrote: > > It's not acceptable (to me) to only show the one newest file, not > > all files that are newer than the target, because often you want to > > know all the newer files. > > You say "It's not acceptable (to me) to only sh

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:05 +0200, Bruno Haible wrote: > $ rm -f mbrtoc32.o > $ make --trace mbrtoc32.o If you remove the target then it should only say that it was rebuilt because the target doesn't exist, regardless of how many other prerequisite are out of date, because you can't even compute t

Re: GNU make troubleshooting

Paul Smith wrote: > It's not acceptable (to me) to only show the one newest file, not all > files that are newer than the target, because often you want to know > all the newer files. You say "It's not acceptable (to me) to only show the one newest file", and I say "A tool that shows me 3.7 KB wor

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 20:46 +0200, Bruno Haible wrote: > The " due to: " is useless, since these files > have not changed since the last compilation. (Suggestion: Reduce this > list by showing only the file with the newest timestamp. Files with > older timestamps are redundant.) I can't explain wh

Re: GNU make troubleshooting

I want to prefix this by saying that there's no question that make's traceability could be improved: I'm not saying nothing needs to be done. On Mon, 2023-07-10 at 20:32 +0200, Bruno Haible wrote: > 1) Print the total of the Makefile and all included Makefiles. >    Like what "gcc -E" does with C

Re: GNU make troubleshooting

> 2) Where is the Makefile source for each command that gets executed? >For each command that gets executed, print not only the command (or >nothing if the line begins with '@'), but also the location (which >Makefile, which line number). > >This would help in a number of situation

Re: GNU Make 4.4.0.91 on Cygwin

> From: Paul Smith > Cc: br...@clisp.org, bug-make@gnu.org > Date: Mon, 20 Feb 2023 10:36:07 -0500 > > Of course "testing on Windows" can mean many different things as there > are so many possible environments "on Windows". I only run one Windows > environment: (a) Windows 10/11 in a VM, (b) usi

Re: GNU Make 4.4.0.91 on Cygwin

On Mon, 2023-02-20 at 14:47 +0200, Eli Zaretskii wrote: > How do you conclude that this "works on Windows"? Before I make a release I test on various systems and the regression test suite must pass with no failures. One of the systems I test on is Windows, so if a release comes out and a test is

Re: GNU Make 4.4.0.91 on Cygwin

> From: Paul Smith > Date: Sun, 19 Feb 2023 14:59:35 -0500 > > On Sun, 2023-02-19 at 20:32 +0100, Bruno Haible wrote: > > All "Device or resource busy" failures are gone. Only the 1 failure > > in category 'misc/general4' is still present. > > Hm. This is a test of this: > https://savannah.gnu.

Re: GNU Make 4.4.0.91 on Cygwin

On Sun, 2023-02-19 at 17:20 -0500, Ken Brown wrote: > > Hm.  This is a test of this: > > https://savannah.gnu.org/bugs/index.php?57674 > > > > which explicitly removes PATH from the environment completely.  It > > should use a default PATH, which should mean "echo" works even so.  > > I'm not real

Re: GNU Make 4.4.0.91 on openSUSE Leap 15.2

On Sun, 2023-02-19 at 22:15 +0100, Bruno Haible wrote: > gnulib/m4/glob.m4 contains a test for this bug: Thanks! I adapted this for GNU make and hopefully it will correctly detect this issue. # Check the system to see if it provides GNU glob. If not, use our # local version. Also avoid versio

Re: GNU Make 4.4.0.91 on Cygwin

On 2/19/2023 2:59 PM, Paul Smith wrote: On Sun, 2023-02-19 at 20:32 +0100, Bruno Haible wrote: All "Device or resource busy" failures are gone. Only the 1 failure in category 'misc/general4' is still present. Hm. This is a test of this: https://savannah.gnu.org/bugs/index.php?57674 which exp

Re: GNU Make 4.4.0.91 on openSUSE Leap 15.2

Paul Smith wrote: > In the abstract it would be nice to have configure detect the bug in > glibc and use our local version of glob on those systems, but writing a > runtime test for the actual bug would be "interesting". gnulib/m4/glob.m4 contains a test for this bug: AC_CACHE_CHECK([whethe

Re: GNU Make 4.4.0.91 on openSUSE Leap 15.2

On Sun, 2023-02-19 at 21:23 +0100, Bruno Haible wrote: > - The wildcard.9 failure (well-known), In the abstract it would be nice to have configure detect the bug in glibc and use our local version of glob on those systems, but writing a runtime test for the actual bug would be "interesting". Howe

Re: GNU Make 4.4.0.91 on Solaris 11.4 (32-bit)

Paul Smith wrote: > > Somehow your fix for archives.12 and archives.13 does not work > > in this environment. I'm attaching the config.status. > > That test was accidentally running with 4.4.0.90 still: Oops, sorry. Retested Solaris 11.4 with your latest tests/scripts/features/archives patch. Re

Re: GNU Make 4.4.0.91 on GNU/Hurd

Paul Smith wrote: > > Yes, I see these also on: > > - Debian 11.1 > > - Solaris 11.4 (64-bit) > > - Solaris 11 OmniOS > > - Solaris 11 OpenIndiana > > The patch below should fix it but it's probably not worth the effort of > retesting all these systems. I've retested one of the systems: S

Re: GNU Make 4.4.0.91 on Solaris 11.4 (32-bit)

On Sun, 2023-02-19 at 21:53 +0100, Bruno Haible wrote: > Somehow your fix for archives.12 and archives.13 does not work > in this environment. I'm attaching the config.status. That test was accidentally running with 4.4.0.90 still: # /export/home/bruno/make-4.4.0.90/build-32/tests/scripts/feat

Re: GNU Make 4.4.0.91 on GNU/Hurd

On Sun, 2023-02-19 at 21:46 +0100, Bruno Haible wrote: > > You'll likely see this same issue with the other systems that don't > > provide a "cc". > > Yes, I see these also on: >   - Debian 11.1 >   - Solaris 11.4 (64-bit) >   - Solaris 11 OmniOS >   - Solaris 11 OpenIndiana The patch below shoul

Re: GNU Make 4.4.0.91 on GNU/Hurd

Paul Smith wrote: > > Only 2 test failures, in category 'features/archives', due to "cc: > > not found". > > Argh, I forgot to change the CC thing everywhere in that test. I've > fixed this. > > You'll likely see this same issue with the other systems that don't > provide a "cc". Yes, I see the

Re: GNU Make 4.4.0.91 on AIX 7.2

On Sun, 2023-02-19 at 21:20 +0100, Bruno Haible wrote: > Paul Smith wrote: > > Does touch on AIX support the "-a" option? > > Yes. "-a" is a documented option of /usr/bin/touch, and it works > fine. Hm. Maybe the AIX filesystem has issues with subsecond timestamps, or something. If you have the

Re: GNU Make 4.4.0.91 on AIX 7.2

Paul Smith wrote: > Does touch on AIX support the "-a" option? Yes. "-a" is a documented option of /usr/bin/touch, and it works fine. Bruno

Re: GNU Make 4.4.0.91 on AIX 7.2

On Sun, 2023-02-19 at 20:55 +0100, Bruno Haible wrote: >   - 1 from category 'features/include'. Hm. I don't know what the problem is here; clearly we shouldn't be printing this line twice: *** work/features/include.base.37 Sun Feb 19 19:38:21 2023 --- work/features/include.log.37S

Re: GNU Make 4.4.0.91 on Cygwin

On Sun, 2023-02-19 at 20:32 +0100, Bruno Haible wrote: > All "Device or resource busy" failures are gone. Only the 1 failure > in category 'misc/general4' is still present. Hm. This is a test of this: https://savannah.gnu.org/bugs/index.php?57674 which explicitly removes PATH from the environmen

Re: GNU Make 4.4.0.91 on GNU/Hurd

On Sun, 2023-02-19 at 20:25 +0100, Bruno Haible wrote: > On GNU/Hurd, much fewer test failures than with 4.4.0.90 > : > > Only 2 test failures, in category 'features/archives', due to "cc: > not found". Argh, I forgot to change th

Re: GNU Make 4.4.0.90 on GNU/Hurd

Paul Smith wrote: > > In other words, on GNU/Hurd, one should use 'glob' and 'globfree', > > not 'glob64' and 'globfree64'. Even though the libc is glibc and > > support for large files (> 2 GiB) is enabled. > > > > The culprit seems to be the glob.in.h file. > > As far as I can tell from the log

Re: GNU Make 4.4.0.90 on GNU/Hurd

On Sun, 2023-02-19 at 12:34 +0100, Bruno Haible wrote: > In other words, on GNU/Hurd, one should use 'glob' and 'globfree', > not 'glob64' and 'globfree64'. Even though the libc is glibc and > support for large files (> 2 GiB) is enabled. > > The culprit seems to be the glob.in.h file. As far as

Re: GNU Make 4.4.0.90 on GNU/Hurd

I wrote: > On GNU/Hurd (from 2022), I get 13 test failures: > > New: > > - 4 failures in category 'features/archives', due to "cc: not found". > > Already reported in > https://lists.gnu.org/archive/html/bug-make/2022-10/msg00218.html : > > - 5 failures in category 'features/jobserver' >

Re: GNU Make 4.4.0.90 on CentOS Stream

On Sun, 2023-01-15 at 11:47 +0100, Bruno Haible wrote: > On CentOS stream, 3 tests fail, in the output-sync category. I have been struggling to reproduce these output-sync failures for a few weeks now and I'm about to give up in frustration. I can't even get past the first step. It would be good

Re: GNU Make 4.4.0.90 on AIX 7.2

On Tue, Jan 17, 2023 at 3:14 AM Bruno Haible wrote: > On AIX 7.2, in 64-bit mode, with the environment variables settings > > CC="xlc -q64 -qthreaded -qtls"; > CXX="xlC -q64 -qthreaded -qtls"; > AR="ar -X 64"; > NM="nm -X 64 -B"; > export CC CXX AR NM > > (with which I build many GNU pac

Re: GNU Make 4.4.0.90 on AIX 7.2

> * 1 failure in category 'features/include'. > The command 'touch -a test.foo' is being printed twice, not just once. > This could be a bug in the AIX exec* functions, which don't properly > separate the stdout and stderr of the parent process and child process > in some situations. (I had

Re: GNU Make 4.4.0.90 on Cygwin

On Cygwin 2.9.0 (running in Windows 10), I see these test failures: * Same failures as seen in GNU/Hurd: - 5 failures in category 'features/jobserver' - 2 failures in category 'features/parallelism' - 1 failure in category 'features/recursion' - 1 failure in category 'functions/shell'

Re: GNU Make 4.4.0.90 on AIX 7.2

On AIX 7.2, in 64-bit mode, with the environment variables settings CC="xlc -q64 -qthreaded -qtls"; CXX="xlC -q64 -qthreaded -qtls"; AR="ar -X 64"; NM="nm -X 64 -B"; export CC CXX AR NM (with which I build many GNU packages successfully), I get 20 test failures: * 16 failures in catego

Re: GNU Make 4.4.0.90 on Solaris 11 OpenIndiana

On Solaris 11 OpenIndiana (from 2022), aside from the 4 well-known test failures in 'features/archives', in 64-bit mode I also see a test failure in category 'features/output-sync', with an error message "timeout after 10 seconds". I don't know why only this 1 out of 3 output-sync tests (compared

Re: GNU Make 4.4.0.90 on Solaris 11 OmniOS

On Solaris 11 OmniOS, aside from the well-known 4 features/archives failures, I see 3 test failures in the 'features/output-sync' category. They come with an error message "timeout after 10 seconds". Here the logs: - 32-bit build: makeerror-4.4.0.90-x86_64-pc-solaris2.11-thix.tar.gz - 64-bit b

Re: GNU Make 4.4.0.90 on Solaris 11.4

The same 4 failures in features/archives ("cc: not found") also occur on Solaris 11.4. On this platform, 'cc' does not exist in $PATH, but 'gcc' does. Find attached the logs. makeerror-4.4.0.90-x86_64-pc-solaris2.11-q6is.tar.gz Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on GNU/Hurd

On Sun, 2023-01-15 at 15:49 +0100, Bruno Haible wrote: >   - 5 failures in category 'features/jobserver' >   - 2 failures in category 'features/parallelism' >   - 1 failure in category 'features/recursion' >   - 1 failure in category 'functions/shell' It seems these are the same errors from the pr

Re: GNU Make 4.4.0.90 on Debian 11.1

On Sun, 2023-01-15 at 09:44 -0500, Paul Smith wrote: > We'll have to override these settings in that test. OK I made a change that will hopefully address this.

Re: GNU Make 4.4.0.90 on macOS 12

On Sun, 2023-01-15 at 15:53 +0100, Bruno Haible wrote: > On macOS 12.5 / arm64 I see two test failures: >   - output-sync >   - temp_stdin Thanks, I fixed this one.

Re: GNU Make 4.4.0.90 on Manjaro 17 — bi-arch problem

On Sun, 2023-01-15 at 14:58 +0100, Bruno Haible wrote: > On Manjaro Linux 17, installed from manjaro-kde-17.1.12-stable- > x86_64.iso, > in 32-bit mode, the build failure reported in >   https://lists.gnu.org/archive/html/bug-make/2022-10/msg00212.html > still occurs. Find the build details attache

Re: GNU Make 4.4.0.90 on macOS 12

On macOS 12.5 / arm64 I see two test failures: - output-sync - temp_stdin Find attached the log files. The machine is gcc104.fsffrance.org. makeerror-4.4.0.90-aarch64-apple-darwin21.6.0-050w.tar.gz Description: application/compressed-tar

Re: GNU Make 4.4.0.90 on GNU/Hurd

On GNU/Hurd (from 2022), I get 13 test failures: New: - 4 failures in category 'features/archives', due to "cc: not found". Already reported in https://lists.gnu.org/archive/html/bug-make/2022-10/msg00218.html : - 5 failures in category 'features/jobserver' - 2 failures in category 'featu

Re: GNU Make 4.4.0.90 on Debian 11.1

On Sun, 2023-01-15 at 09:35 -0500, Paul Smith wrote: > On Sun, 2023-01-15 at 15:33 +0100, Bruno Haible wrote: > > In this test you have the lines > > > >   # Fallback if configure did not find AR > >   my $ar = get_config('AR') || 'ar'; > > > > Why not do the same for CC? > > > >   my $cc = get_

Re: GNU Make 4.4.0.90 on Debian 11.1

On Sun, 2023-01-15 at 15:33 +0100, Bruno Haible wrote: > In this test you have the lines > >   # Fallback if configure did not find AR >   my $ar = get_config('AR') || 'ar'; > > Why not do the same for CC? > >   my $cc = get_config('CC') || 'cc'; Yes, that's how it's done in other tests. I'll

Re: GNU Make 4.4.0.90 on Debian 11.1

Paul Smith wrote: > > But instead I see 4 test failures in the 'features/archives' > > category. > > These are because: > > ! /bin/sh: 1: cc: not found > > Why is there no C compiler on this system? Or is the problem that it's > not on the PATH for some reason? Indeed, there is no 'cc' nor '

Re: GNU Make 4.4.0.90 on Debian 9.1

On Sun, 2023-01-15 at 14:52 +0100, Bruno Haible wrote: > - The wilcard.9 failure reported in >   https://lists.gnu.org/archive/html/bug-make/2022-10/msg00123.html >   and discussed in >   https://lists.gnu.org/archive/html/bug-make/2022-10/msg00158.html >   is still present. This is due to bugs in

Re: GNU Make 4.4.0.90 on Debian 11.1

On Sun, 2023-01-15 at 14:36 +0100, Bruno Haible wrote: > But instead I see 4 test failures in the 'features/archives' > category. These are because: ! /bin/sh: 1: cc: not found Why is there no C compiler on this system? Or is the problem that it's not on the PATH for some reason?

Re: GNU Make 4.4.0.90 on Manjaro 17 — bi-arch problem

On Manjaro Linux 17, installed from manjaro-kde-17.1.12-stable-x86_64.iso, in 32-bit mode, the build failure reported in https://lists.gnu.org/archive/html/bug-make/2022-10/msg00212.html still occurs. Find the build details attached. makeerror-manjaro17-32bit.tar.gz Description: application/co

  1   2   3   4   5   6   >