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

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

Follow-up Comment #2, bug #66743 (group make): This fails with GNU Make 4.3 because it doesn't support the FIFO-based jobserver. If you don't want to try to debug it, your other option is to add the *--jobserver-style=pipe* to your top-level make invocation. That will force the e

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

Follow-up Comment #1, bug #66743 (group make): That error message with the "internal error:" prefix was only ever printed by GNU Make 4.3. It's no longer generated by GNU Make 4.4.1. There is a similar error, but it doesn't use the "internal error:" prefix. So, I

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

07:13:43 PM UTC Severity: 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

[bug #66665] Prefix character not applied to all canned recipe lines if provided by variable

verity: 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

[bug #66658] GNU make should show features with --version

Follow-up Comment #2, bug #66658 (group make): For the short term you can use: echo '$(info $(.FEATURES))' | make -f- 2>/dev/null (the redirect is to avoid the "make: *** No targets. Stop" message. ___ Reply to

[bug #66658] GNU make should show features with --version

Follow-up Comment #1, bug #66658 (group make): Suggestion is by Basile Starynkevitch (France) working on https://github.com/RefPerSys/RefPerSys/ (GPLv3 inference engine for Linux) ___ Reply to this item at: <https://savannah.gnu.

[bug #66658] GNU make should show features with --version

URL: Summary: GNU make should show features with --version Group: make Submitter: None Submitted: Mon 13 Jan 2025 11:05:11 AM UTC Severity: 3 - Normal Item Group

[bug #66627] A target-specific variable side-effect on eval

Follow-up Comment #1, bug #66627 (group make): I forgot to register before posting this bug report. ___ Reply to this item at: <https://savannah.gnu.org/bugs/?66627> ___ Message se

[bug #66627] A target-specific variable side-effect on eval

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

Re: Bug in GNU make if -j used with very high values

On Wed, 2024-12-18 at 15:29 -0500, Dianne Skoll wrote: > On Debian GNU/Linux 12 with default settings, the command: > >    make -j 7 > > hangs. This is https://savannah.gnu.org/bugs/index.php?66499

Bug in GNU make if -j used with very high values

emaphore. Yes, I realize this is a ridiculous edge-case, but I think it's still technically a bug. Regards, Dianne.

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #10, bug #66499 (group make): Sounds like you had to do some investigation. Thank you for your report. ___ Reply to this item at: <https://savannah.gnu.org/bugs/?66

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #9, bug #66499 (group make): Sure! I was testing a patch for gcc (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114542) regarding the -flto= option. When testing edge cases for , I found gcc hanging, which was caused by a blocked GNUmake child process. Of course these values

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #8, bug #66499 (group make): Thanks for review, Paul. Heiko, do you mind sharing the scenario that causes you to specify such high value of jobs? ___ Reply to this item at: <https://savannah.gnu.org/bugs/?66

[bug #66324] Typo in documentation?

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

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Update of bug #66499 (group make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:None => M

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #6, bug #66499 (group make): Thanks a lot for a quick fix! ___ Reply to this item at: <https://savannah.gnu.org/bugs/?66499> ___ Message sent via Savannah

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #5, bug #66499 (group make): Tested on sun 64 and 32 bits and linux 64 and 32 bits. Here is an example $ ls makefile $ cat makefile all:; $(info hello, world) $ make -j68 make: warning: number of jobs is limited to 16384 hello, world make: 'all' is up to da

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

Update of bug #66490 (group make): Item Group: Bug => Documentation Status: Not A Bug => None Open/Closed: Closed => Open Summary: pattern substitution with % does not match

[bug #66490] pattern substitution with % does not match suffixes

Follow-up Comment #3, bug #66490 (group make): Hi, Thanks for the explanations about how this is the intended result. However the reason I created a bug report is that I think in that case the documentation deserves some clarification. > a pattern match means: the "%" match

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #4, bug #66499 (group make): Patch sv66499.diff in the attachment sets the write side of the pipe to non blocking mode and keeps writing until EAGAIN. Tested on linux 64 bit. i am going to test on solaris and report later. (file #56663

Re: [bug #66499] Parameter for option -j seems not to be validated and can cause hangs

On Sun, 2024-12-01 at 17:12 +0100, Henrik Carlqvist wrote: > On Sun,  1 Dec 2024 09:10:04 -0500 (EST) > "Paul D. Smith" wrote: > > F_GETPIPE_SZ will work on Linux but it's not portable (not part of > > POSIX > > fcntl) > > Suggestion: Use F_GETPIPE_SZ as a limit when it does exist, if not, > use

Re: [bug #66499] Parameter for option -j seems not to be validated and can cause hangs

On Sun, 1 Dec 2024 09:10:04 -0500 (EST) "Paul D. Smith" wrote: > F_GETPIPE_SZ will work on Linux but it's not portable (not part of POSIX > fcntl) Suggestion: Use F_GETPIPE_SZ as a limit when it does exist, if not, use some arbitrary big value which usually will be "big enough with a margin". I

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #3, bug #66499 (group make): F_GETPIPE_SZ will work on Linux but it's not portable (not part of POSIX fcntl) ___ Reply to this item at: <https://savannah.gnu.org/bug

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #2, bug #66499 (group make): > Unfortunately I know of no way to determine how large a pipe a system > supports short of filling one up. What about fcntl with F_GETPIPE_SZ? ___ Reply to this item at:

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

Follow-up Comment #1, bug #66499 (group make): The problem is that we are trying to write that many tokens into the jobserver pipe, and it's hanging because there is nothing reading from the pipe. The number of jobs that can be managed depends on how large a pipe the system sup

[bug #66500] Caching of timestamps prevents proper builds

Additional Item Attachment, bug #66500 (group make): File name: makefile Size: 74B <https://file.savannah.gnu.org/file/makefile?file_id=56658> AGPL NOTICE These attachments are served by Savane. You can download the corresponding source code of Savane at

[bug #66500] Caching of timestamps prevents proper builds

URL: Summary: Caching of timestamps prevents proper builds Group: make Submitter: gwj Submitted: Sat 30 Nov 2024 03:15:29 PM UTC Severity: 3 - Normal Item Group:

[bug #66499] Parameter for option -j seems not to be validated and can cause hangs

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

[bug #66490] pattern substitution with % does not match suffixes

Update of bug #66490 (group make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: To add to what Dmitry says: a pattern match mean

[bug #66490] pattern substitution with % does not match suffixes

Follow-up Comment #1, bug #66490 (group make): In the case of patsubst pattern '.%' does not match input 'bcd.efg'. Same for substitution references. Try something like $(patsubst %.efg,%,$(A)) or B:=$(A:.efg=) ___ R

[bug #66490] pattern substitution with % does not match suffixes

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 Status

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

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

[bug #66381] Stem splitting and directory prefix reconstruction for static pattern rules.

Follow-up Comment #2, bug #66381 (group make): The proposed patch will not work well on MS-Windows: it assumes that '/' is the only possible directory separator character, and it ignores the possibility of a drive letter in file names. I hope these non-portable aspects will be fixed b

[bug #66381] Stem splitting and directory prefix reconstruction for static pattern rules.

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

[bug #66381] Stem splitting and directory prefix reconstruction for static pattern rules.

Follow-up Comment #1, bug #66381 (group make): This commit introduces two user visible changes. 1. Split the stem for static pattern rules to dirname and basename. With this feature static pattern rules do the same stem splitting and directory prefix reconstruction as implicit search does for

[bug #66381] Stem splitting and directory prefix reconstruction for static pattern rules.

URL: Summary: Stem splitting and directory prefix reconstruction for static pattern rules. Group: make Submitter: dgoncharov Submitted: Sat 26 Oct 2024 08:38:30 PM UTC Severit

[bug #57962] make attempts to execute a directory found on PATH

Update of bug #57962 (group make): Fixed Release:None => 4.4 ___ Reply to this item at: <https://savannah.gnu.org/bugs/?57962> __

[bug #66359] "make" doesnt see the "Makefile.mak" in directory

Update of bug #66359 (group make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: As Marti

[bug #66359] "make" doesnt see the "Makefile.mak" in directory

Follow-up Comment #1, bug #66359 (group make): https://www.gnu.org/software/make/manual/html_node/Makefile-Names.html documents which names are looked for by default. Makefile.mak isn’t one of them. That suggests that the content is unlikely to have been created for use with Gnu Make, so I wish

[bug #66359] "make" doesnt see the "Makefile.mak" in directory

Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.81 Operating System: MS Windows Fixed Release: None

[bug #66343] building with -Wstring-compare triggers severe warnings

Follow-up Comment #1, bug #66343 (group make): These seem to be generated by using the streq() macro: /* Test if two strings are equal. Is this worthwhile? Should be profiled. */ #define streq(a, b) \ ((a) == (b) || \ (*(a) == *(b) && (*(a) == '\0' || !strcmp ((a) + 1

[bug #66343] building with -Wstring-compare triggers severe warnings

URL: Summary: building with -Wstring-compare triggers severe warnings Group: make Submitter: None Submitted: Thu 17 Oct 2024 11:10:41 AM UTC Severity: 3 - Normal

  1   2   3   4   5   6   7   8   9   10   >