[bug #67517] Inconsistent variable $@ if target has an escaped wildcard like \*

Follow-up Comment #1, bug #67517 (group make): The same happens if '?' or '[' is used. ___ Reply to this item at: <https://savannah.gnu.org/bugs/?67517> ___ Messa

[bug #67517] Inconsistent variable $@ if target has an escaped wildcard like \*

ity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 4.4.1 Operating System: POSIX-Based Fixed Release

Re: [BUG] undefined variable used in recipe before undefine directive

On Thu, 2025-09-11 at 23:00 +0200, Alejandro Colomar wrote: > Are target-specific variables only available in the recipe? Yes, they are (your original example didn't say that you wanted to use the variable in the prerequisites list as well): https://www.gnu.org/software/make/manual/html_node/Targ

Re: [BUG] undefined variable used in recipe before undefine directive

Hi Paul, On Thu, Sep 11, 2025 at 08:59:42AM -0400, Paul Smith wrote: > On Wed, 2025-09-10 at 23:38 +0200, Alejandro Colomar wrote: > > The reason I want to be able to undefine the variable name is to not > > need to come up with unique names in variables used within a recipe. > > That's why I imme

Re: [BUG] undefined variable used in recipe before undefine directive

On Thursday, September 11, 2025, Alejandro Colomar wrote: > Hi Paul, > > On Thu, Sep 11, 2025 at 08:59:42AM -0400, Paul Smith wrote: > > On Wed, 2025-09-10 at 23:38 +0200, Alejandro Colomar wrote: > > > The reason I want to be able to undefine the variable name is to not > > > need to come up wit

Re: [BUG] undefined variable used in recipe before undefine directive

Hi Philip, On Thu, Sep 11, 2025 at 02:26:37PM -0700, Philip Guenther wrote: > Hmm, if the regexp file names match a consistent, unambiguous pattern > (like, all have the suffix “.ref”) then the command in the recipe could > match that from the prerequisite list with $(filter %.ref, $^) so that the

Re: [BUG] undefined variable used in recipe before undefine directive

On Wed, 2025-09-10 at 23:38 +0200, Alejandro Colomar wrote: > The reason I want to be able to undefine the variable name is to not > need to come up with unique names in variables used within a recipe. > That's why I immediately undefine it; to be able to reuse the name, > making sure that old valu

Re: [BUG] undefined variable used in recipe before undefine directive

matic transformations to every rule, but then you're really writing in a different language, one that effectively compiles to GNU Make, with only the debugging tools for the lower level language. ____ From: bug-make-bounces+martin.dorey=hds@gnu.org on behalf of Alejandr

Re: [BUG] undefined variable used in recipe before undefine directive

Hi Paul, On Wed, Sep 10, 2025 at 05:08:09PM -0400, Paul Smith wrote: > On Wed, 2025-09-10 at 22:33 +0200, Alejandro Colomar wrote: > >  alx@debian:~/tmp/bug$ cat Makefile | nl -ba > >   1 MAKEFLAGS += --warn-undefined-variables > >   2 > >   3 foo := foo &

Re: [BUG] undefined variable used in recipe before undefine directive

lavors.html has four subsections rather than the titular two, one of which talks about the really newfangled (POSIX Issue 8 only being standardized in 2024) :::= assignment. From: bug-make-bounces+martin.dorey=hds@gnu.org on behalf of Alejandro Colomar Sent:

Re: [BUG] undefined variable used in recipe before undefine directive

On Wed, 2025-09-10 at 22:33 +0200, Alejandro Colomar wrote: >  alx@debian:~/tmp/bug$ cat Makefile | nl -ba >   1 MAKEFLAGS += --warn-undefined-variables >   2 >   3 foo := foo >   4 >   5 all:; echo $(foo) >   6 >   7 undefine foo >

[BUG] undefined variable used in recipe before undefine directive

Hi, I think this looks like a bug, unless I'm forgetting some details about how variables are expanded within recipes. alx@debian:~/tmp/bug$ ls Makefile alx@debian:~/tmp/bug$ cat Makefile | nl -ba 1 MAKEFLAGS += --warn-undefined-variables

[bug #59956] Recipes inside conditionals can break the parser

Update of bug #59956 (group make): Depends on: => bugs #64185 ___ Reply to this item at: <https://savannah.gnu.org/bugs/?59956> ___ Message

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Follow-up Comment #17, bug #64185 (group make): See also bug #59956 ___ Reply to this item at: <https://savannah.gnu.org/bugs/?64185> ___ Message sent via Savannah https://savannah.g

[bug #59956] Recipes inside conditionals can break the parser

Update of bug #59956 (group make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #11: I believe we have chosen a way forward for this

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Follow-up Comment #16, bug #64185 (group make): You are apparently correct: I visited a random bug on a different project and I can't add myself. Nevermind! ___ Reply to this item at: <https://savannah.gnu.org/bug

[bug #67162] Windows build fails due to subdomain change for cgit

Update of bug #67162 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:None => SCM T

[bug #66974] Irregular target introduction of unmatched wildcard include

Update of bug #66974 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System: POSIX-Based => Any F

[bug #66490] Documentation of patsubst function could be more clear

Update of bug #66490 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System: POSIX-Based => Any F

[bug #67046] .EXTRA_PREREQS causes a segfault.

Update of bug #67046 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:None => SCM T

[bug #66424] Infinite loop when cross-compiling glibc-2.12.2

Follow-up Comment #2, bug #66424 (group make): In glibc, please see: commit 2d7ed98add14f75041499ac189696c9bd3d757fe Author: Sergei Trofimovich AuthorDate: Tue Sep 13 13:39:13 2022 -0400 Commit: Siddhesh Poyarekar CommitDate: Tue Sep 13 13:45:32 2022 -0400 Makerules: fix MAKEFLAGS

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Follow-up Comment #15, bug #64185 (group make): (Perhaps you have more access than I do. There’s now a trash icon against my name, so I think I could unsubscribe, but I don’t see any other editing controls.) ___ Reply to this item at

[bug #66424] Infinite loop when cross-compiling glibc-2.12.2

Follow-up Comment #1, bug #66424 (group make): The problem is that this build recreates the file */home/cendio/cenbuild/repo/rpmbuild/BUILD/glibc-2.12.2/build/bits/stdio_lim.st*, and that cause the file */home/cendio/cenbuild/repo/rpmbuild/BUILD/glibc-2.12.2/build/bits/stdio_lim.h* to be

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Follow-up Comment #14, bug #64185 (group make): Just to note: if you go all the way to the bottom of a Savannah issue you should be able to expand the "Mail Notification Carbon-Copy List" section and add yourself directly, without needing to add

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Follow-up Comment #13, bug #64185 (group make): (Sorry for the noise but, unlike Harry, I don't seem to be seeing bug-make mails for this bug, just what are now its dupes, https://savannah.gnu.org/bugs/?67168 and https://savannah.gnu.org/bugs/?

[bug #64259] Regression in master: make ignores statements it should not ignore.

Update of bug #64259 (group make): Status:None => Duplicate Open/Closed:Open => Closed Operating System:None => Any ___ Follow-up C

[bug #67168] `ifeq` nested within the `else` of another `ifeq` causes "missing endif" error.

Update of bug #67168 (group make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #4: I reverted the change for bug #64185 so make b

[bug #67428] [PATCH] documentation of $(findstring ...)

Update of bug #67428 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:None => Any F

[bug #67391] The -d and --debug options

Update of bug #67391 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:None => SCM T

Re: [bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Thank you, Harry From: Paul D. Smith Sent: Monday, August 25, 2025 9:32:59 PM To: Clauson, Harry (CHICO-C) Subject: [bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe Update of bug #64185 (group make): Status: Fixed =&

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

Update of bug #64185 (group make): Status: Fixed => None Open/Closed: Closed => Open Fixed Release: SCM => None ___ Follow-up Co

[bug #65908] "missing 'endif'" error should show the line the conditional started at

Update of bug #65908 (group make): Summary: Make fails with 'Makefile:3857: *** missing 'endif'. Stop. => "missing 'endif'" error should show the line the conditional started at ___

[bug #63818] V=1 stopped working for Linux kernel module builds with make-4.4

Update of bug #63818 (group make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: This is marked as a doc bug, but I am not sur

[bug #66915] Avoid rebuilding existing order-only prerequisites.

Update of bug #66915 (group make): Open/Closed:Open => Closed ___ Follow-up Comment #2: I think, based on the discussion in the mailing list, that this change isn't quite the direction we want

[bug #67265] Expand each recipe line just before it's run, rather than all lines up-front

Update of bug #67265 (group make): Summary: $(file) in commands is executed too early => Expand each recipe line just before it's run, rather than all lines up-front ___ Reply to this item at: <https://savan

[bug #67424] Allocate the message buffer for $(info ...) on the heap instead of stack.

Update of bug #67424 (group make): Status:None => Duplicate Open/Closed:Open => Closed Fixed Release:None => SCM ___ Follow-up C

[bug #67428] [PATCH] documentation of $(findstring ...)

Additional Item Attachment, bug #67428 (group make): Name: 0001-doc-make.texi-Less-confusing-example-for-findstring.patch Size: 1KiB <https://file.savannah.gnu.org/file/0001-doc-make.texi-Less-confusing-example-for-findstring.patch?file_id=57533> AGPL NOTICE These attachments are

[bug #67428] [PATCH] documentation of $(findstring ...)

URL: Summary: [PATCH] documentation of $(findstring ...) Group: make Submitter: None Submitted: Thu 14 Aug 2025 04:06:38 PM UTC Severity: 3 - Normal Item Group:

Re: [bug #67424] Allocate the message buffer for $(info ...) on the heap instead of stack.

On Wed, 13 Aug 2025 at 22:35, Dmitry Goncharov wrote: > Follow-up Comment #1, bug #67424 (group make): > > Next someone will want to set an env variable with 64M long name. > You can always create an artificial scenario that overflows the stack. > On the other hand, heap alloc

[bug #67424] Allocate the message buffer for $(info ...) on the heap instead of stack.

Follow-up Comment #1, bug #67424 (group make): Next someone will want to set an env variable with 64M long name. You can always create an artificial scenario that overflows the stack. On the other hand, heap allocations are more expensive

[bug #67424] Allocate the message buffer for $(info ...) on the heap instead of stack.

URL: Summary: Allocate the message buffer for $(info ...) on the heap instead of stack. Group: make Submitter: None Submitted: Wed 13 Aug 2025 02:42:04 PM UTC Severity: 3 - No

[bug #67391] The -d and --debug options

Update of bug #67391 (group make): Item Group:None => Documentation ___ Reply to this item at: <https://savannah.gnu.org/bugs/?67391> ___ Message

[bug #67391] The -d and --debug options

URL: Summary: The -d and --debug options Group: make Submitter: None Submitted: Sun 03 Aug 2025 01:38:47 PM UTC Severity: 3 - Normal Item Group: None

Re: [bug #67265] $(file) in commands is executed too early

Zack Weinberg (30 June 2025 19:23) wrote: > It doesn't have to control what happens inside a shell command. All > it has to do is split the recipe into individual commands *before* > expanding anything -- this is perfectly possible, since \n and ; > *don't* separate commands when they come from ex

Re: [bug #67265] $(file) in commands is executed too early

On Mon, Jun 30, 2025, 9:14 AM Zack Weinberg wrote: > Follow-up Comment #5, bug #67265 (group make): > > > > We're not going to make $(file...) a special case that expands > differently > > than everything else. > > I'm surprised you insist on this. Ther

Re: [bug #67265] $(file) in commands is executed too early

On Mon, 2025-06-30 at 15:03 -0400, Zack Weinberg wrote: > On Mon, Jun 30, 2025, at 2:21 PM, Paul D. Smith wrote: > > Follow-up Comment #6, bug #67265 (group make): > > Make's expansion rules are very simple.  When some text undergoes > > expansion, make goes through

Re: [bug #67265] $(file) in commands is executed too early

On Mon, Jun 30, 2025, at 2:21 PM, Paul D. Smith wrote: > Follow-up Comment #6, bug #67265 (group make): >> If you are determined that anything that looks like $(...) or ${...} must be >> consumed by expansion, you could get the same effect by having $(file >> REDIRECTION,

Re: [bug #67265] $(file) in commands is executed too early

On Mon, 2025-06-30 at 13:23 -0400, Zack Weinberg wrote: > > It's not $(file) that is causing this effect it's how all make > > functions work of any kind. There is always expansion just before a > > command is executed. When a command is sent to the shell make has > > no further control of it. > >

[bug #67265] $(file) in commands is executed too early

Follow-up Comment #6, bug #67265 (group make): > If you are determined that anything that looks like $(...) or ${...} must be > consumed by expansion, you could get the same effect by having $(file > REDIRECTION, CONTENTS) expand to a different sequence of characters, which > w

Re: [bug #67265] $(file) in commands is executed too early

On Mon, Jun 30, 2025, at 1:43 PM, Tim Murphy wrote: > On Mon, 30 Jun 2025 at 18:14, Zack Weinberg wrote: >> p.s. I do insist that this is a bug, not a feature request. The existing >> behavior is strictly less useful than the requested behavior, and surprising >> to boot.

Re: [bug #67265] $(file) in commands is executed too early

On Mon, Jun 30, 2025, at 12:55 PM, Tim Murphy wrote: > How can make control what happens inside a shell command? How can > make wait until mkdir is executed by the shell and then expand $(file) > before the next shell command executes? It doesn't have to control what happens inside a shell comman

Re: [bug #67265] $(file) in commands is executed too early

On Mon, 30 Jun 2025 at 18:14, Zack Weinberg wrote: > > p.s. I do insist that this is a bug, not a feature request. The existing > behavior is strictly less useful than the requested behavior, and > surprising > to boot. If I understand you then you want to use $(file) to

[bug #67265] $(file) in commands is executed too early

Follow-up Comment #5, bug #67265 (group make): > We're not going to make $(file...) a special case that expands differently > than everything else. I'm surprised you insist on this. There is plenty of precedent for using the same notation for expandable and non-expandable primi

Re: [bug #67265] $(file) in commands is executed too early

On Mon, 2025-06-30 at 17:55 +0100, Tim Murphy wrote: > That cannot work logically. How can make control what happens inside > a shell command?  How can make wait until mkdir is executed by the > shell and then expand $(file) before the next shell command executes? I think the ask is that the expan

Re: [bug #67265] $(file) in commands is executed too early

On Mon, 30 Jun 2025, 16:41 Zack Weinberg, wrote: > Follow-up Comment #3, bug #67265 (group make): > > 1. The point of the bug report is that $(file) *should be* processed later > than other $(...) constructs. Having said that, it would probably be > sufficient, and perhaps

[bug #67265] $(file) in commands is executed too early

Update of bug #67265 (group make): Item Group:None => Enhancement ___ Follow-up Comment #4: It is not a bug. All expansion in recipes happens the same way, regardless of whether what's being exp

[bug #67265] $(file) in commands is executed too early

Follow-up Comment #3, bug #67265 (group make): 1. The point of the bug report is that $(file) *should be* processed later than other $(...) constructs. Having said that, it would probably be sufficient, and perhaps a less invasive change, to do $(...) expansion of *each line of a command list

[bug #67265] $(file) in commands is executed too early

Follow-up Comment #2, bug #67265 (group make): Hi, Make always expands a command before executing it in the shell - this is why your $(file) is getting done before mkdir. I don't think you need $(file) here at all since you can use the shell to create a file with something like mkd

[bug #67265] $(file) in commands is executed too early

Follow-up Comment #1, bug #67265 (group make): (Tested only with 4.3, but I don't see anything related to $(file) in the NEWS for 4.4. Problem originally found by Stack Overflow user 'stefanct' here <https://stackoverflow.com/questions/7281395/output-multiline-variable-to-a-

[bug #67265] $(file) in commands is executed too early

URL: Summary: $(file) in commands is executed too early Group: make Submitter: zackw Submitted: Mon 30 Jun 2025 02:50:00 PM GMT Severity: 3 - Normal Item Group:

Re: bug-report: make does not read Makefile on Windows in case sensitive folder

> From: Espen Ottar > CC: "bug-make@gnu.org" > Date: Mon, 30 Jun 2025 13:39:30 + > > Ok, my bad. I was using make 3.81 from > https://gnuwin32.sourceforge.net/packages/make.htm Try the one from ezwinports site.

Sv: bug-report: make does not read Makefile on Windows in case sensitive folder

Ok, my bad. I was using make 3.81 from https://gnuwin32.sourceforge.net/packages/make.htm Fra: bug-make-bounces+espen.ottar=greendigital...@gnu.org på vegne av Eli Zaretskii Sendt: mandag 30. juni 2025 15:23 Til: Espen Ottar Kopi: bug-make@gnu.org Emne: Re

Re: bug-report: make does not read Makefile on Windows in case sensitive folder

> From: Espen Ottar > Date: Mon, 30 Jun 2025 07:47:41 + > > On Windows it is possible to enable case sensitivity on a per-folder basis . > (using fsutil.exe) > When case sensitivity is enabled, make fails to read "Makefile" (with capital > M) > The workaround is to use "make -f Makefile" bu

bug-report: make does not read Makefile on Windows in case sensitive folder

On Windows it is possible to enable case sensitivity on a per-folder basis . (using fsutil.exe) When case sensitivity is enabled, make fails to read "Makefile" (with capital M) The workaround is to use "make -f Makefile" but that should not be necessary

[bug #67195] surprising behavior with prerequisite search via vpath

Follow-up Comment #4, bug #67195 (group make): The patch in the attachments adds logging of directory search. $ ~/src/gmake/make/l64/make --debug=s -R Directory searching for 'all'. 'all' not found by directory search. Directory searching for '../include/fil

[bug #67195] surprising behavior with prerequisite search via vpath

Additional Item Attachment, bug #67195 (group make): File name: sv67195_vpath_logging.diff Size: 19KiB <https://file.savannah.gnu.org/file/sv67195_vpath_logging.diff?file_id=57286> AGPL NOTICE These attachments are served by Savane. You can download the corresponding source c

[bug #67195] surprising behavior with prerequisite search via vpath

Follow-up Comment #3, bug #67195 (group make): > Furthermore, if we remove (or ignore) the 'all' target and directly specify > '../include/file.x' as a goal: > >> make ../include/file.x > > then this results in: > > make: '../lib

[bug #67195] surprising behavior with prerequisite search via vpath

Follow-up Comment #2, bug #67195 (group make): Your reply confirms what I suspected, namely that make indeed searches for the relative path '../include/file.x' instead of just the file 'file.x'. I think this is wrong but one may perhaps have a different opinion. Furthermo

[bug #67195] surprising behavior with prerequisite search via vpath

Follow-up Comment #1, bug #67195 (group make): 'all' depends on prerequisite '../include/file.x'. Make performs directory search for prerequisite '../include/file.x'. Prerequisite '../include/file.x' matches directory search pattern '%.x'. M

[bug #67195] surprising behavior with prerequisite search via vpath

Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 4.3 Operating System: POSIX-Based Fixed Release: None Triage

[bug #67168] `ifeq` nested within the `else` of another `ifeq` causes "missing endif" error.

Follow-up Comment #3, bug #67168 (group make): It seems clear that there are too many "broken" makefiles out there to simply make this change in the next release. We will need at least one release which generates warnings but continues to interpret the makefile as it did before, t

[bug #67168] `ifeq` nested within the `else` of another `ifeq` causes "missing endif" error.

Follow-up Comment #2, bug #67168 (group make): The effort required to generate a minimal reproducer, never mind a git bisection, is surely worth thanks and a prompt response, even if it's a discouraging one. Said reproducer and the original https://956806.bugs.gentoo.org/attachment.cgi?id=9

[bug #67168] `ifeq` nested within the `else` of another `ifeq` causes "missing endif" error.

Follow-up Comment #1, bug #67168 (group make): Bisected to: https://cgit.git.savannah.gnu.org/cgit/make.git/commit/?id=07fcee35f058a876447c8a021f9eb1943f902534 ___ Reply to this item at: <https://savannah.gnu.org/bugs/?67

[bug #67168] `ifeq` nested within the `else` of another `ifeq` causes "missing endif" error.

Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: SCM Operating System: None Fix

[bug #67162] Windows build fails due to subdomain change for cgit

Follow-up Comment #1, bug #67162 (group make): Thanks for that note. I'll look into it. I do remember seeing some notes about changes in this area, in the last month, but didn't realize we were impacted. ___ Reply to th

[bug #67162] Windows build fails due to subdomain change for cgit

URL: Summary: Windows build fails due to subdomain change for cgit Group: make Submitter: None Submitted: Tue 27 May 2025 11:25:58 AM UTC Severity: 3 - Normal It

[bug #67046] .EXTRA_PREREQS causes a segfault.

Follow-up Comment #2, bug #67046 (group make): Thanks Dmitry I will check out this patch. ___ Reply to this item at: <https://savannah.gnu.org/bugs/?67046> ___ Message sent via Sa

[bug #67046] .EXTRA_PREREQS causes a segfault.

Additional Item Attachment, bug #67046 (group make): File name: sv67046.diff Size: 3KiB <https://file.savannah.gnu.org/file/sv67046.diff?file_id=57162> AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Sav

[bug #67046] .EXTRA_PREREQS causes a segfault.

Follow-up Comment #1, bug #67046 (group make): A user reported a crash caused by .EXTRA_PREREQS carrying a large number of prerequisites. The original bug report is here https://lists.gnu.org/archive/html/bug-make/2025-04/msg9.html. $ ls makefile $ cat makefile list := $(shell for n in

[bug #67046] .EXTRA_PREREQS causes a segfault.

Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: SCM Operating System: Any Fixed Release: None Triage Status

[bug #66974] Irregular target introduction of unmatched wildcard include

URL: Summary: Irregular target introduction of unmatched wildcard include Group: make Submitter: None Submitted: Tue 01 Apr 2025 08:15:07 PM UTC Severity: 3 - Normal

[bug #66915] Avoid rebuilding existing order-only prerequisites.

URL: Summary: Avoid rebuilding existing order-only prerequisites. Group: make Submitter: dgoncharov Submitted: Sat 15 Mar 2025 12:18:34 PM UTC Severity: 3 - Normal

[bug #66915] Avoid rebuilding existing order-only prerequisites.

Additional Item Attachment, bug #66915 (group make): File name: sv66915.diff Size: 5KiB <https://file.savannah.gnu.org/file/sv66915.diff?file_id=57021> AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Sav

[bug #66915] Avoid rebuilding existing order-only prerequisites.

Follow-up Comment #1, bug #66915 (group make): Suggested by Britton Kerin here https://lists.gnu.org/archive/html/bug-make/2025-03/msg6.html. This is an excerpt from that email. "What confuses me is that since the explicitly requested foo exists and isn't out of date with respect

Re: [bug #66870] memory corruption

On Wed, 2025-03-05 at 18:23 -0500, Dmitry Goncharov wrote: > There is a buffer overflow when shellflags contains characters > special to shell, like =. > See https://savannah.gnu.org/bugs/?65588. I got really fed up with the current command line parser and I have a fully-rewritten version that is

[bug #66870] memory corruption

Follow-up Comment #2, bug #66870 (group make): There is a buffer overflow when shellflags contains characters special to shell, like =. See https://savannah.gnu.org/bugs/?65588. ___ Reply to this item at: <https://savannah.gnu.org/b

[bug #66870] memory corruption

Follow-up Comment #1, bug #66870 (group make): To make the crash happen earier and more often, edit src/job.c to make default_shell be really really long (like 70 characters). ___ Reply to this item at: <https://savannah.gnu.org/b

[bug #66870] memory corruption

URL: <https://savannah.gnu.org/bugs/?66870> Summary: memory corruption Group: make Submitter: None Submitted: Wed 05 Mar 2025 01:18:16 AM UTC Severity: 3 - Normal Item Grou

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #6, bug #66500 (group make): [comment #5 comment #5:] > The rule for foo/tar is lacking a recipie. In this case make has no reason to > invalidate the cached mtime of foo/tar. As explained earlier make has no idea > that the recipie for foo touched foo/tar. Any recipi

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #5, bug #66500 (group make): The rule for foo/tar is lacking a recipie. In this case make has no reason to invalidate the cached mtime of foo/tar. As explained earlier make has no idea that the recipie for foo touched foo/tar. Any recipie for foo/tar, even a empty one, is

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #4, bug #66500 (group make): [comment #3 comment #3:] > This statement applies as make is traversing the graph and is considering a > target. When make is considering baz foo/tar exists and is older. > This is the typical issue when a recipie builds something o

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #3, bug #66500 (group make): This statement applies as make is traversing the graph and is considering a target. When make is considering baz foo/tar exists and is older. This is the typical issue when a recipie builds something other than

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #2, bug #66500 (group make): "Make has no idea that the recipe touched foo/tar." And this is the problem. The manual says: "The recompilation must be done if the source file, or any of the header files named as prerequisites, is more recent than the object

[bug #66237] Grouped target dependencies don't function properly in dry-run mode

Follow-up Comment #1, bug #66237 (group make): I can reproduce this with make-4.3, however, the latest make build from master behaves correctly here. $ make --version GNU Make 4.4.90 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL

[bug #66500] Caching of timestamps prevents proper builds

Follow-up Comment #1, bug #66500 (group make): There is this makefile in the attachment. baz: foo/tar touch baz foo/tar: foo foo: bar -mkdir foo touch foo/tar Make is correct. Make is doing what this makefile tells make to do. The user touches bar and runs make. Make goes through

[bug #66743] internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo2924992'.

Follow-up Comment #7, bug #66743 (group make): Yes, something must be using MAKE=make or something like that, either in the environment or command line. Make itself never resets the MAKE variable, if it's already set (as far as I&#x

[bug #66743] internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo2924992'.

Follow-up Comment #6, bug #66743 (group make): > I believe if you invoke it as /home/buildroot/make it will be preserved, > including the full path, and if you invoke it as make it will use that > instead. I'm invoking the make binary with the absolute path at /home/buildroot/

[bug #66743] internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo2924992'.

Follow-up Comment #5, bug #66743 (group make): [comment #3 comment #3:] > is it expected that it is the same version of make as was executed at the top > level? By default, it's the same as the make that was invoked at the top-level, as documented [https://www.gnu.org/software/

[bug #66743] internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo2924992'.

Follow-up Comment #4, bug #66743 (group make): GNU Make sets the MAKE variable to whatever the command line invocation of make was. I believe if you invoke it as */home/buildroot/make* it will be preserved, including the full path, and if you invoke it as *make* it will use that instead

[bug #66743] internal error: invalid --jobserver-auth string 'fifo:/tmp/GMfifo2924992'.

Follow-up Comment #3, bug #66743 (group make): Ah, it does work if I run the build like this: PATH=/home/buildroot/make:$PATH make host-libxml-parser-perl -j2 --shuffle=reverse Is it expected that when invoking a sub-make as is being done [https://github.com/buildroot/buildroot/blob

  1   2   3   4   5   6   7   8   9   10   >