[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

[bug #63016] Recursive variable references itself (eventually) when exporting to $(shell)

Follow-up Comment #2, bug #63016 (group make): I may come to regret posting this, as the current git code is working well for me here. I did ask for this change. That's why I feel duty-bound to report that it bit me today. martind@stormy:~/tmp/D160959$ cat Makefile generate = $(or $(1),$

[bug #66324] Typo in documentation?

URL: Summary: Typo in documentation? Group: make Submitter: None Submitted: Fri 11 Oct 2024 04:05:25 PM UTC Severity: 3 - Normal Item Group: Documentation

[bug #65759] handling of "-" and "--" on command line

Update of bug #65759 (group make): Item Group: Bug => Documentation Status:None => Fixed Assigned to:None => psmith Op

[bug #65777] add const misc global RO arrays

Update of bug #65777 (group make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None

[bug #66268] Messed up error message about a failure to remove an intermediate file.

Update of bug #66268 (group make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => Any Fixe

[bug #66273] An explicitly mentioned file is not intermediate.

Update of bug #66273 (group make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => Any Fixe

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Follow-up Comment #6, bug #65588 (group make): [comment #5 comment #5:] > I am experiencing a situation with GNU Make 4.4.1 that is I expect will be resolved with the changes under consideration. i expect the same. > Can you possibly advise me how I can test it in my environment. I will

[bug #65588] A buffer overrun in handling of .SHELLFLAGS.

Follow-up Comment #5, bug #65588 (group make): I am experiencing a situation with GNU Make 4.4.1 that is I expect will be resolved with the changes under consideration. Can you possibly advise me how I can test it in my environment. I will build make if needed. In the following 4 one-liners

[bug #66273] An explicitly mentioned file is not intermediate.

Additional Item Attachment, bug #66273 (group make): File name: sv66273_explicit_file_with_double_colon.diff Size: 3KiB <https://file.savannah.gnu.org/file/sv66273_explicit_file_with_double_colon.diff?file_id=56466> AGPL NOTICE These attachments are served by Savane. You can do

[bug #66273] An explicitly mentioned file is not intermediate.

Follow-up Comment #1, bug #66273 (group make): Make incorrectly considers an explicitly mentioned file intermediate when the file is a target of a double colon rule. $ ls makefile $ cat makefile hello.x: %.x: %.q; $(info $@ from $<) hello.q::; touch $@ $ # this is make built from master $

[bug #66273] An explicitly mentioned file is not intermediate.

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

[bug #66268] Messed up error message about a failure to remove an intermediate file.

Additional Item Attachment, bug #66268 (group make): File name: sv66268_intermfile_removal_error_msg.diff Size: 2KiB <https://file.savannah.gnu.org/file/sv66268_intermfile_removal_error_msg.diff?file_id=56464> AGPL NOTICE These attachments are served by Savane. You can downlo

[bug #66268] Messed up error message about a failure to remove an intermediate file.

Follow-up Comment #1, bug #66268 (group make): Messed up error message about a failure to remove an intermediate file. $ cat makefile all: hello.x %.x: b/%.q; $(info $@ from $<) b/%.q:; mkdir b; touch $@; chmod -w b $ make mkdir b; touch b/hello.q; chmod -w b hello.x from b/hello.q r

[bug #66268] Messed up error message about a failure to remove an intermediate file.

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

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

an target 'obj2'. Must remake target 'obj2'. touch obj2 Successfully remade target file 'obj2'. It feels to me that in the `&:` case, it's failing to remember that it's fake-built `obj1` when looking

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

Follow-up Comment #5, bug #65908 (group make): [comment #4 comment #4:] > > it would be better that make provides the infos about that line not mis-matched `endif'. > > Sorry but I don't understand what you mean by "that line". Which line is it that make sho

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

Update of bug #65908 (group make): Item Group: Bug => Enhancement ___ Follow-up Comment #4: > it would be better that make provides the infos about that line not mis-matched `endif&#x

[bug #66073] $? is set incorrectly in the case of grouped targets.

Follow-up Comment #4, bug #66073 (group make): > Maybe the comment intended to use "foo.r" instead? Right, I meant "foo.r" instead of "foo.q". Sorry for confusion. > For example if I use the original description and touch foo.p / bar.p first, then I s

[bug #66073] $? is set incorrectly in the case of grouped targets.

Follow-up Comment #3, bug #66073 (group make): I don't understand why the previous comment is talking about foo.q. In what way would it ever be correct for foo.q to appear in "$?"? foo.q is one of the targets and "$?" lists the out of date prerequisites. Maybe th

[bug #66073] $? is set incorrectly in the case of grouped targets.

Follow-up Comment #2, bug #66073 (group make): I am interested in this topic because this affects Linux kernel build system (Kbuild). If foo.q does not appear in $?, I do not know how to make the combination of if_changed and the grouped target working. foo.p foo.q &: foo.r FORCE $(

[bug #66073] $? is set incorrectly in the case of grouped targets.

Follow-up Comment #1, bug #66073 (group make): A user reported an issue here https://lists.gnu.org/archive/html/help-make/2024-08/msg1.html. Here is a copy of that email which contains a good description of the issue. Hi. I have two similar Makefiles. [Makefile1] .PHONY: all all

[bug #66073] $? is set incorrectly in the case of grouped targets.

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

[bug #66050] add option --shuffle=nosort

Follow-up Comment #3, bug #66050 (group make): I am not a fan having the --shuffle argument modify the behavior of $(wildcard ...) as they are completely disjoint facilities that have nothing to do with each other. IMO it will be confusing. The result of wildcard has swung back and forth

[bug #65739] Add warnings circular-dep and circular-extra-dep.

Update of bug #65739 (group make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None

[bug #66030] --trace only shows the "primary" ($@) target

Update of bug #66030 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operati

[bug #66037] An infinite loop with MAKEFLAGS on the command line.

Update of bug #66037 (group make): Status:None => Fixed Open/Closed:Open => Closed Operating System:None => Any Fixe

[bug #66018] Recommendation: document .ONESHELL behavior in sections concerning line prefixes [@+-]

Update of bug #66018 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixe

[bug #65999] make -d could be more descriptive WRT phony targets

Update of bug #65999 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operati

[bug #65982] make --trace does not explain remade include files

Update of bug #65982 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operati

[bug #65917] --dry-run doesn't handle pattern rules with multiple targets correctly

Update of bug #65917 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixe

[bug #66030] --trace only shows the "primary" ($@) target

Follow-up Comment #5, bug #66030 (group make): You are talking about what make knows and what, of the things it knows, it should print in this situation. I don't disagree with any of that. I'm talking about what make _actually does today_. There can be no disagreement about that, sin

[bug #66050] add option --shuffle=nosort

Follow-up Comment #2, bug #66050 (group make): > Are you suggesting a way to always build prerequisites > in an order sorted by their name? The opposite: build *WILDCARD* prerequisites in an order *NOT* sorted by their name. $ touch {a..z} # Current: $ make -E "all: *; @echo $^&quo

[bug #66030] --trace only shows the "primary" ($@) target

Follow-up Comment #4, bug #66030 (group make): I'm not trying to be argumentative, really, but I still feel like we're not quite coming to closure on the same topic so let me try one more time. It seems to me there's a significant difference between these two rules: foo.h

[bug #66030] --trace only shows the "primary" ($@) target

Follow-up Comment #3, bug #66030 (group make): I think we are just disagreeing over a matter of technical semantics. Make is showing the target it is currently considering, and which it determined to be out of date and so forced make to run the recipe. In your example, that target is "

[bug #65999] make -d could be more descriptive WRT phony targets

Update of bug #65999 (group make): Summary: make --debug=makefile could be more descriptive => make -d could be more descriptive WRT phony targets ___ Reply to this item at: <https://savannah.gnu.org/bugs/

[bug #65999] make --debug=makefile could be more descriptive

Follow-up Comment #1, bug #65999 (group make): Whether or not you specify "makefile" is not relevant for this issue; these messages are printed while building the normal targets. In fact they're printed even with "basic" debug level. However they can b

[bug #66050] add option --shuffle=nosort

Follow-up Comment #1, bug #66050 (group make): I'm sorry but I don't understand this issue. Can you clarify? I don't know what the --shuffle option has to do with sorting: shuffled prerequisites are never sorted (that would go against the entire concept). Are you suggesting

[bug #66050] add option --shuffle=nosort

ALTDIRFUNC | GLOB_NOSORT, NULL, &gl)) Or manually shuffle by special target .FIRST? Prerequisites of this special target will be reordered to be made first, i.e. to be build with priority. It will provide hint to GNU Make how to schedule big monolith targets in parallel build and provide manual fi

[bug #66030] --trace only shows the "primary" ($@) target

Follow-up Comment #2, bug #66030 (group make): I'm sorry, while trying to put together the simplest possible test case I think I posted the wrong example. Let me try again. Consider this slightly revamped version: $ cat Makefile targets := foo.h foo.c .PHONY: all all: $(targets)

[bug #66037] An infinite loop with MAKEFLAGS on the command line.

Follow-up Comment #1, bug #66037 (group make): Make enters an infinite loop when some option and MAKEFLAGS= are specified on the command line. Sometimes rather than entering an infinite loop, make exits with an error message, because internal state of getopt is messed up. Here is an example of a

[bug #66037] An infinite loop with MAKEFLAGS on the command line.

Additional Item Attachment, bug #66037 (group make): File name: sv66037_fix.diff Size: 4KiB <https://file.savannah.gnu.org/file/sv66037_fix.diff?file_id=56324> File name: sv66037_test.diff Size: 2KiB <https://file.savannah.gnu.org/file/sv66037_test.dif

[bug #66037] An infinite loop with MAKEFLAGS on the command line.

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

[bug #66030] --trace only shows the "primary" ($@) target

Follow-up Comment #1, bug #66030 (group make): The purpose of that statement is to tell you why make elects to run that recipe, not what it thinks that recipe will do. The reason this line is shown the way it is, is that foo.h is the target make is trying to build, and foo.h is the target that

[bug #66030] --trace only shows the "primary" ($@) target

URL: Summary: --trace only shows the "primary" ($@) target Group: make Submitter: None Submitted: Fri 26 Jul 2024 06:55:37 PM UTC Severity: 3 - Normal Item Group

[bug #66018] Recommendation: document .ONESHELL behavior in sections concerning line prefixes [@+-]

URL: Summary: Recommendation: document .ONESHELL behavior in sections concerning line prefixes [@+-] Group: make Submitter: None Submitted: Wed 24 Jul 2024 05:33:17 PM UTC Sev

[bug #66011] dependencies after a non-existing file are silently ignored

Follow-up Comment #6, bug #66011 (group make): Yes; if you structure your makefile pattern rules as Dmitry suggests (which is definitely the right way to do it: you really don't want to add "extra" prerequisites to a pattern rule beyond only the exact prerequisite that its built fr

[bug #66011] dependencies after a non-existing file are silently ignored

Follow-up Comment #5, bug #66011 (group make): In my case the nonexisting.h doesn't exist, because I did a refactorization that removed it, but I forgot to update the header list in the Makefile. After a while I noticed that making changes to certain headers was not a reason for recompile

[bug #66011] dependencies after a non-existing file are silently ignored

Update of bug #66011 (group make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #4: Indeed the prereq

[bug #66011] dependencies after a non-existing file are silently ignored

Follow-up Comment #3, bug #66011 (group make): If you need such a prerequisite and the prerequisite is missing, then the makefile needs to have a rule to build such a prerequisite. Depending on your situation this rule can be either a proper rule or dummy rule like nonexisting.h:; In the end

[bug #66011] dependencies after a non-existing file are silently ignored

Follow-up Comment #2, bug #66011 (group make): If all the files listed in the prerequisites do exist, the pattern rule that I wrote works fine. To quote the GNU Make Manual section 10.5.1: > There may also be prerequisites that do not use ‘%’; such a prerequisite attaches to every file made

[bug #66011] dependencies after a non-existing file are silently ignored

Follow-up Comment #1, bug #66011 (group make): This rule %.o : %.c $(HEADERS) Makefile does not apply because nonexisting.h does not exist. To make there is simply no rule in this makefile to build *.o files. You want to do something like this instead hello.o: $(HEADERS) Makefile %.o : %.c

[bug #66011] dependencies after a non-existing file are silently ignored

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

[bug #65999] make --debug=makefile could be more descriptive

URL: Summary: make --debug=makefile could be more descriptive Group: make Submitter: boyski Submitted: Wed 17 Jul 2024 02:59:13 PM UTC Severity: 3 - Normal Item

[bug #65982] make --trace does not explain remade include files

Follow-up Comment #3, bug #65982 (group make): Oh, sorry, I didn't R enough of TFM but at least a little doc bug will be fixed as a result. Sorry for the waste of time otherwise. ___ Reply to this item at: <https://savannah

[bug #65982] make --trace does not explain remade include files

Update of bug #65982 (group make): Item Group: Bug => Documentation ___ Follow-up Comment #2: This is intended behavior. The docs for the trace option: https://www.gnu.org/software/make/man

[bug #65982] make --trace does not explain remade include files

Follow-up Comment #1, bug #65982 (group make): > ... also includes 2 generated makefiles ... Actually the attached version has only one generated makefile (x1.mk) but the situation is unaffected. ___ Reply to this item at: <

[bug #65982] make --trace does not explain remade include files

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: None Triage Status

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Update of bug #65972 (group make): Status:None => Not A Bug Open/Closed:Open => Closed Operating System: POSIX-Based

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Follow-up Comment #6, bug #65972 (group make): I'm fine with closing this bug, but I don't know how to do it. ___ Reply to this item at: <https://savannah.gnu.org/bugs/?65972> ___

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Follow-up Comment #5, bug #65972 (group make): This seems to do the trick: .SECONDARY: $(OBJS) $(foreach T,$(TESTS),$($T-test_OBJDEPS)) $(HELPERS:%=%.wrap) So your suggestion covered it by ~80%. Thanks! ___ Reply to this item at

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Follow-up Comment #4, bug #65972 (group make): I don't think we will allow "going back" to the old behavior. That behavior was just a bug (IMO) and also, your makefile is fragile by relying on it (if that object file was ever mentioned anywhere else outside of a pattern rule,

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Follow-up Comment #3, bug #65972 (group make): Thanks for your response. I only saw it after adding my last comment. > .SECONDARY: $(OBJS) $(foreach T,$(TESTS),$($T-test_OBJDEPS)) That doesn't do the trick, but it seems to go into the right direction. I'll keep

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Follow-up Comment #2, bug #65972 (group make): I bisected this manually to 510e5ce ("[SV 60188] Explicit prereqs cannot be intermediate files"). So apparently this change was made deliberately in the context of bug #60188. I wish it was possible to restore the historical behavior. I w

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Follow-up Comment #1, bug #65972 (group make): Unfortunately the output shown in the comment here is not the important part. The important part is why make decided that the -test file needs to be updated, so you need to look at how make processes the target that is being rebuilt, not the thing

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

Additional Item Attachment, bug #65972 (group make): File name: sid.logSize: 356KiB <https://file.savannah.gnu.org/file/sid.log?file_id=56249> File name: f40.logSize: 597KiB <https://file.savannah.gnu.org/file/f40.log?file

[bug #65972] Change in dependency treatment between GNU make 4.3 and 4.4.1

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

[bug #65917] --dry-run doesn't handle pattern rules with multiple targets correctly

Follow-up Comment #1, bug #65917 (group make): I've come up with this patch: diff --git a/src/remake.c b/src/remake.c index ee8971e7..9d33351f 100644 --- a/src/remake.c +++ b/src/remake.c @@ -1090,11 +1090,16 @@ notice_finished_file (struct file *file) d->file->update_st

[bug #65917] --dry-run doesn't handle pattern rules with multiple targets correctly

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: Any Fixed Re

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

Follow-up Comment #3, bug #65908 (group make): Then, it would be better that make provides the infos about that line not mis-matched `endif'. ___ Reply to this item at: <https://savannah.gnu.org/bug

Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

On Sat, 22 Jun 2024 15:49:26 + Martin Dorey wrote: > Um, Henrik... 4.4.90 is the latest in git: Yes, I now see that you are right and that has been the "version number" of all commits in git since version 4.4.1. > ...the de facto OS/2 maintainer... Whoops, my bad... I did remember when supp

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

Follow-up Comment #2, bug #65908 (group make): You should review this Git patch: https://public-inbox.org/git/9d14c08ca6cc06cdf8fb4ba33d2470053dca3966.1712591504.git...@ttaylorr.com/ See this section of the GNU Make manual: > Extra spaces are allowed and ignored at the beginning of

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

Follow-up Comment #1, bug #65908 (group make): I see line 3857 is the end of Makefile... and that the likely reason the testcase is so large is because it's hard to work out where the if/endif matching has gone astray. For me, running on Linux, the error initially reported is different:

Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

he if/endif directives, as with the Linux kernel makefiles, will reply further in Savannah... From: bug-make-bounces+martin.dorey=hds@gnu.org on behalf of Henrik Carlqvist Sent: Saturday, June 22, 2024 08:21 To: Henrik Carlqvist Cc: invalid.nore...@gnu.org

Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

On Sat, 22 Jun 2024 16:57:17 +0200 Henrik Carlqvist wrote: > > Used make is 'GNU Make v4.4.90' from git repo whose head is commit e3f938, > > and I'm working on OS/2. > > > > v4.4.1 works fine. > > In lack of OS/2 maintainer the official GNU Make dropped support for OS/2 > somewhere around vers

Re: [bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

> Used make is 'GNU Make v4.4.90' from git repo whose head is commit e3f938, > and I'm working on OS/2. > > v4.4.1 works fine. In lack of OS/2 maintainer the official GNU Make dropped support for OS/2 somewhere around version 4.4. It seems as if some unofficial fork was done at https://github.com

[bug #65908] Make fails with 'Makefile:3857: *** missing 'endif'. Stop.

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

[bug #65863] release failing jobs last when -j and -O in use

URL: Summary: release failing jobs last when -j and -O in use Group: make Submitter: None Submitted: Sun 09 Jun 2024 10:28:12 PM UTC Severity: 3 - Normal Item Gr

[bug #65773] [PATCH] win32: on VC always make PDB debugging symbols for Release

Follow-up Comment #2, bug #65773 (group make): [comment #1 comment #1:] > This patch is fine by me, but I believe we will need a copyright assignment for you to accept this and other patches you sent. > > Would you like me to send you the form to fill and the instructions to go with i

[bug #65771] [PATCH] restore Visual C 6 and newer but older VC 200X builds

Follow-up Comment #3, bug #65771 (group make): Revised "restore Visual C 6 and newer but older VC 200X builds" -more std C types/casts used, no more app specific "_quad_t" type also added a 2nd patch fixing build/compile time, for gnumake on old or very old (2000s era)

[bug #65776] [PATCH 1/3] win32 STAT_LITE

Follow-up Comment #2, bug #65776 (group make): I check my Win2K PC, kernel32.dll has GetFileAttributesEx, my WinME also has GetFileAttributesEx, my Win 95 test box, NO. https://www.betaarchive.com/wiki/index.php?title=Microsoft_KB_Archive/250301 says GFAEx() added Win 98 for Dos Windows family

[bug #65771] [PATCH] restore Visual C 6 and newer but older VC 200X builds

Follow-up Comment #2, bug #65771 (group make): [comment #1 comment #1:] > Thanks. Some comments to the proposed patch: > > @@ -576,8 +578,8 @@ char *ttyname (int); > > /* Define {u,}intmax_t if not defined in or . */ > #if !HAVE_STDINT_H && !HAVE_INTTYPES_H >

[bug #65777] add const misc global RO arrays

Update of bug #65777 (group make): Severity: 3 - Normal => 1 - Wish Assigned to:None => psmith Component Version:None => SCM Tria

[bug #65776] [PATCH 1/3] win32 STAT_LITE

Follow-up Comment #1, bug #65776 (group make): We don't use GetFileAttributesEx because it doesn't exist on old Windows systems, and GNU Make still wants to support those old systems. So I don't think we should make these

[bug #65775] [PATCH 2/2] win32 dir.c eliminate OS specific dir-cache agressive reread vs posix

Update of bug #65775 (group make): Assigned to:None => eliz Component Version:None => SCM Triage Status:None => Medi

[bug #65774] [PATCH] win32: use link time optimization for Visual C Release build

Update of bug #65774 (group make): Severity: 3 - Normal => 2 - Minor Assigned to:None => eliz Component Version:None => SCM Tria

[bug #65773] [PATCH] win32: on VC always make PDB debugging symbols for Release

Update of bug #65773 (group make): Severity: 3 - Normal => 2 - Minor Assigned to:None => eliz Component Version:None => SCM Tria

[bug #65772] [PATCH] win32: don't twice search disk for $(SHELL) unless PATH or SHELL changed

Update of bug #65772 (group make): Severity: 3 - Normal => 1 - Wish Status:None => Wont Fix Assigned to:None => eliz Componen

[bug #65771] [PATCH] restore Visual C 6 and newer but older VC 200X builds

Update of bug #65771 (group make): Severity: 3 - Normal => 2 - Minor Item Group: Enhancement => Build/Install Assigned to:None => eliz Componen

[bug #65777] add const misc global RO arrays

Follow-up Comment #2, bug #65777 (group make): putting up rev 3, save/commit mistakes by me (file #56090) ___ Additional Item Attachment: File name: 0001-job.c-read.c-add-const-to-global-arrays-of-strings-r.patch Size: 9KiB <ht

  1   2   3   4   5   6   7   8   9   10   >