[bug #29253] Memory corruption error when backslash line continuation used in function call

Update of bug #29253 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #2: Thanks for the report

[bug #29245] Bug with DOS Path in Secondary Expansion (with Fix)

Update of bug #29245 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: I agree with Eli: thi

[bug #29244] MSVC Compatibility broken with main.c Revision 1.237 (with Proposal for Fix)

Update of bug #29244 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #29448] pattern rules: % doesn't match empty string

Update of bug #29448 (project make): Item Group: Bug => Enhancement Triage Status:None => Verified ___ Follow-up Comment #1: The behavior is as do

[bug #29104] Directory Search for Link Libraries doesn't work in implicit rules

Update of bug #29104 (project make): Operating System: MS Windows => Any Triage Status:None => Verified ___ Follow-up Comment #3: This is a real bug.

[bug #24486] Have make print a progress report during build?

Update of bug #24486 (project make): Triage Status:None => Major Effort ___ Reply to this item at: ___ Messa

[bug #27714] expansion of $(shell) in target forces serialization of targets

Update of bug #27714 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #10: I'm going to close t

[bug #30328] Fast echo (with code proposal)

Update of bug #30328 (project make): Triage Status:None => Medium Effort ___ Follow-up Comment #1: Is it really true that this is an issue? The only "echo" commands that can be sped up are ones th

[bug #28983] forcing a target matching a pattern rule shadows the rule's actions

Update of bug #28983 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #8: A few things. First,

[bug #28525] Parens in path names do not work correctly anymore

Update of bug #28525 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #28425] Literal HTML markup on webpage

Update of bug #28425 (project make): Item Group:None => Documentation Status:None => Fixed Assigned to:None => psmith Open/Closed:

[bug #29665] .PHONY included makefiles are rebuilt but not reread

Update of bug #29665 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: This is not a bug. I

[bug #28230] $(eval) does not understand multiline

Update of bug #28230 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: As Philip mentions, t

[bug #27825] win64 fix for config.h.W32.template

Update of bug #27825 (project make): Item Group:None => Bug ___ Reply to this item at: ___ Messa

[bug #20542] Regression: windows gnumake + MKS shell + Special Shell Chars

Update of bug #20542 (project make): Item Group:None => Bug ___ Reply to this item at: ___ Messa

[bug #28189] SIGPIPE when gmake invoked recursively and vpath specified

Update of bug #28189 (project make): Item Group:None => Bug Triage Status:None => Verified ___ Follow-up Comment #1: In the new CVS code w

[bug #29025] problem with odd directory names with spaces and/or parentheses

Update of bug #29025 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #2: Make doesn't support

[bug #105] Parallel builds should order by slowest-first

Update of bug #105 (project make): Triage Status:None => Major Effort ___ Reply to this item at: ___ Message s

[bug #20067] Unescaped meta characters in makefile database outputs

Update of bug #20067 (project make): Triage Status:None => Medium Effort ___ Follow-up Comment #1: It's never been a goal that the output of "make -p" should be a valid makefile that can be reused

[bug #15338] make: stripping leading ./ causes flaky results

Update of bug #15338 (project make): Status:None => Duplicate Open/Closed:Open => Closed Component Version:None => 3.81

[bug #27381] wildcard function acts differently than in 3.81

Update of bug #27381 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #4: It doesn't look like

[bug #27809] several win64 fixes

Follow-up Comment #6, bug #27809 (project make): Thanks Ozkan. A few comments about the parts of the patch that are not Windows-specific. First you mention compiler warning fixes for UNIX, but none of the changes you mention fix any warnings I see on my UNIX tests (different platforms but using

[bug #30340] dependency handling

Follow-up Comment #2, bug #30340 (project make): You might read: http://make.mad-scientist.net/autodep.html ___ Reply to this item at: ___ Message sent

[bug #27809] several win64 fixes

Follow-up Comment #9, bug #27809 (project make): I've applied most of the second patch. The first patch is mostly in the w32 area so maybe Eli is a better person to review it? I did have one question about the first patch: you have a change to make.h which adds an include of malloc.h, but later

[bug #27825] win64 fix for config.h.W32.template

Update of bug #27825 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #3: Closed as duplicate.

[bug #27809] several win64 fixes

Follow-up Comment #12, bug #27809 (project make): > It is needed earlier, otherwise line #38 of make.h provides a > prototype for alloca because there is no alloca.h and AIX is > not defined. OK then the other #include should probably be removed. Thanks! __

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Update of bug #30381 (project make): Item Group:None => Enhancement Component Version:None => 3.81 ___ Follow-up Comment #1: This is the documente

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #2, bug #30381 (project make): Actually my example is solved by your suggestion to use a stack of targets. However, if you imagine a pattern rule where every iteration of the rule _grows_, instead of shrinks, then a stack of targets wouldn't help. What about: %.x : %.x.x ; ca

[bug #27809] several win64 fixes

Update of bug #27809 (project make): Assigned to:None => eliz ___ Reply to this item at: ___ Messa

[bug #30312] $(abspath ...) fails with Windows UNC path (with fix)

Update of bug #30312 (project make): Status:None => Fixed Assigned to:None => eliz ___ Reply to this item at:

[bug #27809] several win64 fixes

Update of bug #27809 (project make): Status:None => Fixed ___ Reply to this item at: ___ Messa

[bug #30370] add a shorthand syntax for foreach-eval-call

Update of bug #30370 (project make): Triage Status:None => Medium Effort ___ Reply to this item at: ___ Messa

[bug #30370] add a shorthand syntax for foreach-eval-call

Follow-up Comment #3, bug #30370 (project make): The major issue here, besides the effort involved of course, is finding a syntax or format that is backward compatible, at least enough to avoid breaking a lot of makefiles. I also have to say that the request at stackoverflow.com and the request

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #5, bug #30381 (project make): But it isn't just a matter of infinite recursion; there's a very serious issue of performance as well, even without infinite recursion. Computing pattern rule matches can already take quite a while: if we add more ways in which patterns can recurs

[bug #17381] Compile errors under DJGPP

Update of bug #17381 (project make): Assigned to:None => eliz ___ Follow-up Comment #2: Eli: I don't see this patch in the current CVS version. Is this still needed? Thanks! _

[bug #27590] MSVC Win64 build patch

Update of bug #27590 (project make): Assigned to:None => eliz ___ Follow-up Comment #3: Hi Eli; do you have any thoughts on this change? Is this something we should take? _

[bug #24513] make check failure on AIX 5.3

Update of bug #24513 (project make): Status:None => Works for me Open/Closed:Open => Closed ___ Follow-up Comment #2: No response here so I

[bug #25713] Please note CPPFLAGS required to build on Tru64

Follow-up Comment #1, bug #25713 (project make): I'm not sure the best way to handle this. What's the triplet printed by running "config.guess" on your system? ___ Reply to this item at: _

[bug #26921] line 0: unexpected EOF while looking for matching `"'

Update of bug #26921 (project make): Open/Closed:Open => Closed ___ Follow-up Comment #2: No response so I'm marking this closed. Please add a comment if you still see this and I can reop

[bug #26891] make enters interactive shell

Update of bug #26891 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: In 3.82 we have .SHEL

[bug #17381] Compile errors under DJGPP

Update of bug #17381 (project make): Status:None => Fixed Fixed Release:None => CVS ___ Reply to this item at:

[bug #27590] MSVC Win64 build patch

Update of bug #27590 (project make): Status:None => Fixed Assigned to:eliz => psmith Open/Closed:Open => Closed Fixed Release:

[bug #25713] Please note CPPFLAGS required to build on Tru64

Follow-up Comment #3, bug #25713 (project make): A log would be helpful. The problem is that from what you say, it's not that functions are missing. It seems more like there are errors in the system headers; for example if u_long is not available when compiling getloadavg.c then why not? I can

[bug #25713] Please note CPPFLAGS required to build on Tru64

Follow-up Comment #5, bug #25713 (project make): Hm, that's interesting. Can you check the status of HAVE_BSD_SIGNAL and HAVE_SIGACTION in config.h? Attaching it would be very helpful. Can you check your system to see if there's a man page for bsd_signal() and if so, what it says the calling a

[bug #25713] Please note CPPFLAGS required to build on Tru64

Follow-up Comment #7, bug #25713 (project make): OK, the problem seems to be that in config.h, we have HAVE_BSD_SIGNAL set. But, in the output of the preprocessor for main.c that function is not defined anywhere. So, the C compiler gives it the default prototype where it returns int, instead of

[bug #30463] cannot make include makefile .INTERMEDIATE

Update of bug #30463 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: I suppose it might be

[bug #25713] Please note CPPFLAGS required to build on Tru64

Update of bug #25713 (project make): Item Group: Documentation => Build/Install Status:None => Fixed Assigned to:None => psmith Open/Closed:

[bug #30328] Fast echo (with code proposal)

Follow-up Comment #4, bug #30328 (project make): Make can handle simple quoting without falling back to the shell, including the difference between single- and double-quotes etc. ___ Reply to this item at:

[bug #30551] Add an option to show commands even with @

Update of bug #30551 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: Closed as a duplicate

[bug #30606] mysterious behavior from $(if)

Update of bug #30606 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: Tim is correct; as fa

[bug #30606] mysterious behavior from $(if)

Follow-up Comment #5, bug #30606 (project make): If by "already expanded ... when the template is being defined" you mean after the define T ... endef, then you're not correct. define, by itself, uses deferred expansion (just like "T = $(foo)") and so right after the define the value of T has NO

[bug #30606] mysterious behavior from $(if)

Follow-up Comment #6, bug #30606 (project make): Ugh, my comment got truncated. I used this example: define T b := $(subst aa,,$(1)) yn := $(if $(strip $(b)),y,n) vs := $(vs) $(1):$(yn) endef $(info $(value T)) will show the string that make is storing as the value of T, without any expansio

[bug #30614] Output redirection with &> not parsed correctly in make 3.81 and up

Update of bug #30614 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: See the GNU make manu

[bug #30723] implicit re-executing of subdirs breaks $(origin) with make-3.82

Follow-up Comment #1, bug #30723 (project make): Hm. Is there any way for you to provide a smaller example? I tried to follow your directions but I think the build failed for some other reason, earlier than the problem you hit: make[2]: *** No rule to make target `.../glibc-2.11.2/build/elf/so

[bug #30723] implicit re-executing of subdirs breaks $(origin) with make-3.82

Follow-up Comment #3, bug #30723 (project make): Hm, I believe I found the bug. Please try this patch: --- main.c 19 Jul 2010 07:10:53 - 1.243 +++ main.c 10 Aug 2010 07:12:15 - @@ -2093,6 +2093,7 @@ const char *pv = define_makeflags (1, 1); char

[bug #30723] implicit re-executing of subdirs breaks $(origin) with make-3.82

Update of bug #30723 (project make): Item Group:None => Bug Status:None => Fixed Assigned to:None => psmith Open/Closed:

[bug #30723] implicit re-executing of subdirs breaks $(origin) with make-3.82

Update of bug #30723 (project make): Component Version:None => 3.82 ___ Reply to this item at: ___ Messa

[bug #30612] make-3.82 parse error

Update of bug #30612 (project make): Item Group:None => Bug Assigned to:None => psmith Component Version: CVS => 3.82 Triage Status:

[bug #30612] error parsing library references with multiple objects

Update of bug #30612 (project make): Summary: make-3.82 parse error => error parsing library references with multiple objects ___ Reply to this item at:

[bug #30714] List of shell commands is outdated/Fallback to shell

Follow-up Comment #4, bug #30714 (project make): I don't have any Windows systems; all my systems run Linux or some UNIX variant. So, I can't support Windows myself and I rely on a group of volunteers to maintain that platform (just like with VMS and other non-POSIX platforms). One concern with

[bug #30612] error parsing library references with multiple objects

Update of bug #30612 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => CVS

[bug #30809] Documention for "6.8 Defining Multi-Line Variables" indicates to use "define VARIABLE ="

Update of bug #30809 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: The documentation onl

[bug #30823] double-colon rules not always executed in parallel make

Update of bug #30823 (project make): Triage Status:None => Verified ___ Follow-up Comment #1: Yes, I see this too. It definitely looks like a bug. ___

[bug #30897] simple archive rules broken under make 3.82

Update of bug #30897 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: Duplicate of bug #306

[bug #30833] Bug of color with less? please check

Update of bug #30833 (project make): Item Group: Bug => None Status:None => Not A Bug Open/Closed:Open => Closed Component Version:

[bug #30748] Segmentation violation for SHELL with "strange" character

Update of bug #30748 (project make): Item Group:None => Bug Status:None => Fixed Assigned to:None => psmith Open/Closed:

[bug #30662] Windows build fails due to missing -I option for subproc/misc

Follow-up Comment #5, bug #30662 (project make): I've modified the options for the files that appeared to have CRLF characters in them, but did not have -kb set, to use -kb so they are treated as binary. Please let me know if I've missed any or this causes any issues. __

[bug #30662] Windows build fails due to missing -I option for subproc/misc

Update of bug #30662 (project make): Component Version: CVS => 3.82 Fixed Release:None => CVS ___ Reply to this item at:

[bug #30807] $(LDFLAGS) used in implicit linking rule

Update of bug #30807 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #30762] another make -n exception

Update of bug #30762 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Component Version:

[bug #111] '@' hides useful info sometimes, needs --print_all_cmds

Update of bug #111 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #31002] make picks wrong pattern rule

Follow-up Comment #1, bug #31002 (project make): This is due to this change, from the NEWS file: * WARNING: Backward-incompatibility! The pattern-specific variables and pattern rules are now applied in the shortest stem first order instead of the definition order (variables and rules with

[bug #31003] Some tests fail because of localisation

Follow-up Comment #1, bug #31003 (project make): Hm. I specifically set the LC_ALL environment variable to "C" before invoking tests, which is supposed to revert to the built-in strings and avoid all translations. It may be that the test suite that comes with GNU make 3.81 is not updated in thi

[bug #31002] make picks wrong pattern rule

Follow-up Comment #3, bug #31002 (project make): Ah I see, because the pattern matches different parts of the stem. Good point. Let me discuss with Boris. ___ Reply to this item at: _

[bug #31003] Some tests fail because of localisation

Update of bug #31003 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => 3.82

[bug #31002] make picks wrong pattern rule

Follow-up Comment #7, bug #31002 (project make): I think we should move this to the make-alpha or bug-make lists. I don't think Savannah bug trackers are the right way to address the larger conceptual issues of when backward-compatibility breaks are OK and when they're not.

[bug #31087] .SECONDEXPANSION: of $$< expands to target in pattern prerequisites

Update of bug #31087 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #2: Thanks for the note;

[bug #28456] Expansion of $$< is incorrect

Follow-up Comment #4, bug #28456 (project make): See also duplicate bug #31087 ___ Reply to this item at: ___ Message sent via/by Savannah http://sav

[bug #31110] infinit loop with double-colon rules

Update of bug #31110 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => 3.82

[bug #31149] Rules to build -include makefiles cause unexpected side-effects

Update of bug #31149 (project make): Triage Status:None => Verified Summary: The rule for generation dependency file (%.d) doesn't work => Rules to build -include makefiles cause unexpected side-effects __

[bug #31155] .SECONDEXPANSION: incorrect order only parsing in patterns

Update of bug #31155 (project make): Triage Status:None => Verified ___ Follow-up Comment #1: Hm. This is a side-effect of the performance increase in 3.82, where we do more of the parsing of

[bug #31278] multiple shell commands within one rule invoke separate shell environments

Update of bug #31278 (project make): Status:None => Fixed Fixed Release:None => 3.82 ___ Follow-up Comment #1: The current behavior

[bug #31278] multiple shell commands within one rule invoke separate shell environments

Update of bug #31278 (project make): Open/Closed:Open => Closed ___ Reply to this item at: ___ Messa

[bug #31326] Error message is way too terse

Follow-up Comment #1, bug #31326 (project make): Isn't "Makefile:40" the file/line information you're looking for? ___ Reply to this item at: ___ Messa

[bug #31361] MinGW make inexplicably invokes as.exe

Follow-up Comment #6, bug #31361 (project make): Nothing I've seen so far indicates that this is a bug in make. Make has no visibility into, or even concept of, intermediate files created by your compiler, and it's certainly not going to be deleting them. From what I've seen it's your compiler

[bug #31430] Add support for the BSD "shell assignment" operator (!=)

Follow-up Comment #1, bug #31430 (project make): I've nothing against adding != for portability. However this level of work will require copyright assignment to the FSF. Please let me know if you need paperwork/assistance. Cheers! ___ R

[bug #31743] ?= operator doesn't work correctly with 3.82

Update of bug #31743 (project make): Triage Status:None => Verified ___ Follow-up Comment #1: Actually it doesn't work (always) in 3.81; there's a memory corruption bug here that shows up some

[bug #31762] make -silent behaves like make -ignore

Update of bug #31762 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: This is not a bug. T

[bug #31847] Random errors with parallel build

Follow-up Comment #1, bug #31847 (project make): Have you tried with the latest version (GNU make 3.82)? ___ Reply to this item at: ___ Message sent vi

[bug #31940] trailing slash dropped from nonphony multicharacter targets

Update of bug #31940 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Reply to this item at:

[bug #32362] Typo in online documentation for "define" / "call"

Update of bug #32362 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: The online documentat

[bug #32473] ./ is searched first for included makefiles no matter which --include-dir is set

Update of bug #32473 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: This works as document

[bug #32498] export within $(eval) within a $(call) broken?

Update of bug #32498 (project make): Triage Status:None => Verified ___ Follow-up Comment #2: I don't know, something seems wrong here to me. If you have: export AA $(eval export AB) tst = $(

[bug #32484] FILE_TIMESTAMP_HI_RES is not properly set on AIX

Update of bug #32484 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #2: Duplicate of bug #3248

[bug #31430] Add support for the BSD "shell assignment" operator (!=)

Follow-up Comment #5, bug #31430 (project make): Those lines were never ignored (GNU make never ignores malformed lines). Instead, because the prefix "!" was not recognized, GNU make assumed that it was part of the variable name. If you look at the output of GNU make -p with your sample makefile

[bug #33034] "Makefile:23: *** mixed implicit and normal rules. Stop." for Linux kernel out of source builds

Update of bug #33034 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: This is an intentional

[bug #33125] make fails building android build environment due to memory corruption

Follow-up Comment #3, bug #33125 (project make): So I'm happy to make this change, because it does seem cleaner, but I must confess I don't understand how the original error is caused by it. The code uses isspace() to count spaces the first time through the list. isspace() matches spaces and tab

[bug #32871] Incorrect content returned by $(value) in recipe for target specific variable

Update of bug #32871 (project make): Triage Status:None => Verified ___ Follow-up Comment #1: I agree, this is a bug. ___ Reply to this

[bug #33125] make fails building android build environment due to memory corruption

Update of bug #33125 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

[bug #32753] "struct rlimit stack_limit" not declared "extern" in make.h

Update of bug #32753 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Component Version:

<    1   2   3   4   5   6   7   8   9   10   >