[bug #18872] problem colon after drive letter in prerequisite

Update of bug #18872 (project make): Status:None => Fixed Open/Closed:Open => Closed Component Version:None => 3.81 Fixed Release:

[bug #18561] Why backslash line continuation introduce an extra space

Update of bug #18561 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: It is by design; in f

[bug #18641] GNUmake 3.81, $(error ) sometimes unable to stop make process

Update of bug #18641 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: I understand that thi

[bug #18641] GNUmake 3.81, $(error ) sometimes unable to stop make process

Follow-up Comment #4, bug #18641 (project make): The method for auto-generating dependencies described in the GNU make manual is not the state-of-the-art method. You should check my website http://make.paulandlesley.org and look at the advanced auto-dependency generation description there. This

[bug #18963] -include suppressing errors for too long?

Update of bug #18963 (project make): Item Group: Bug => Documentation ___ Follow-up Comment #3: I can see that the documentation is not clear enough. Perhaps it is trying to be too stylized, to

[bug #19015] Initialisation of variable to "ls" and "find" fails with "**missing separator"

Update of bug #19015 (project make): Status:None => Works for me Open/Closed:Open => Closed ___ Follow-up Comment #1: Sorry, but this is no

[bug #18995] variable origin changes upon export or unexport

Update of bug #18995 (project make): Item Group:None => Enhancement Operating System:None => Any ___ Follow-up Comment #1: Internally to make, a

[bug #19035] Make recompiles source files eventhough the files are not modified

Follow-up Comment #1, bug #19035 (project make): Sorry, but there's nothing we can do unless you provide more details, such as a small example of a makefile that does not work properly for you. Note that Solaris and HP contain SystemV make; GNU make is not intended to be a 100% compatible replac

[bug #19122] $* doesn't work as expected

Update of bug #19122 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: Philip is correct. A

[bug #19183] double-colon pattern rules

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

[bug #19236] Imported variable with trailing backslash messes up make's line parsing in nested evaluations

Update of bug #19236 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: I agree this is unple

[bug #19298] simplify automatic generation of prerequisites example

Update of bug #19298 (project make): Severity: 3 - Normal => 1 - Wish ___ Follow-up Comment #1: Unfortunately not every compiler supports these options. The GNU make manual does not assume that

[bug #19348] Ineffective configure option --disable-case-insensitive-file-system

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

[bug #19309] parallel make issue with archive members

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

[bug #19626] Unexpected environment variable modification in command

Update of bug #19626 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: This is the way make

[bug #16389] Defaults for Objective-C

Follow-up Comment #2, bug #16389 (project make): I don't really understand the urgency around this: why not just add the rules into your makefile if you need them? The built-in rules are just that: built-in; they can be added to or removed in makefiles. I do realize this means that any makefile

[bug #19656] strcmpi does not exist on my system, better use strcasecmp instead

Follow-up Comment #1, bug #19656 (project make): Can you please provide the error messages you received? As far as I know GNU make sources don't use strcmpi() except when compiling for non-POSIX systems. ___ Reply to this item at:

[bug #19448] Re-exec after "include file rebuild" is more dependent on filesystem timestamps than strictly necessary.

Follow-up Comment #3, bug #19448 (project make): Sorry, but you're incorrect about the way original UNIX make worked. In fact, every version of make that I'm familiar with does and has always considered equal timestamps as "up to date". The POSIX standard for make is quite clear about this as w

[bug #16389] Defaults for Objective-C

Follow-up Comment #7, bug #16389 (project make): Icarus: I'm sorry you feel frustrated about the situation. However, I'm not going to discuss it in bug report comments: that's not appropriate. If you want to talk about it you can use one of the public mailing lists, or email me and/or Boris and

[bug #19656] strcmpi does not exist on my system, better use strcasecmp instead

Follow-up Comment #3, bug #19656 (project make): True; I suppose it was never anticipated that anyone would build with --enable-case-insensitive-file-system on a POSIX system (because POSIX systems don't HAVE case-insensitive file systems). Nevertheless, the flag is generic and not tied to Windo

[bug #19448] Re-exec after "include file rebuild" is more dependent on filesystem timestamps than strictly necessary.

Follow-up Comment #6, bug #19448 (project make): In fact, your original idea of passing -W for each included file "foo" so that the re-invoked make would realize it should not be built again WAS implemented (by me) in an earlier version of GNU make. However, it lasted only a few days out in the

[bug #19035] Make recompiles source files eventhough the files are not modified

Update of bug #19035 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Reply to this item at:

[bug #18755] exported var-define and var-define from command line should appear in $(shell ) env

Update of bug #18755 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: Yes, they did; I'm cl

[bug #19656] strcmpi does not exist on my system, better use strcasecmp instead

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

[bug #16389] Defaults for Objective-C

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

[bug #18617] Better debugging facilities: tracing rule invocation.

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

[bug #19900] Target-specific variables not honored for rules generated by $(eval)

Update of bug #19900 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: Closed.

[bug #19975] Add function: $(mtime foo.c) -> 1180203683

Follow-up Comment #2, bug #19975 (project make): Note that GNU make has received a Google Summer of Code project, to implement the ability for users to customize the "out of date" algorithm used by make. You might consider waiting a couple of months and see what comes of that by the end of the s

[bug #20033] parallel (-j2) make with $(eval) construct segfaults

Follow-up Comment #3, bug #20033 (project make): I can reproduce this as well and the fix seems simple enough. The thing that's concerning me is WHY does it only happen with parallel makes? There must be something non-obvious happening here because it doesn't seem to me like parallelism should

[bug #20033] parallel (-j2) make with $(eval) construct segfaults

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

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

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

[bug #20018] Several inaccuracies/miswordings/typos in (texinfo) manual

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

[bug #20133] 'make -p' always uses ':=' for pattern-specific variable assignments

Follow-up Comment #1, bug #20133 (project make): I looked at this briefly and it's tough. In order to get the proper behavior for the target-specific variables, make has to modify the way the variable is stored; once that happens it's pretty hard to reconstruct the way the variable originally ap

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Follow-up Comment #16, bug #15919 (project make): I hear your frustration but I cannot apply patches to the source code that I do not fully grok, even if it is a one-line patch. By this I don't mean just "what does the one line do", which is easy, but rather why is that line necessary, why is it

[bug #20394] vpath directive drops entries

Follow-up Comment #2, bug #20394 (project make): It's not exactly correct to say that GNU make caches directories from the 10th on, but you're on exactly the right track; thanks for the note. What make actually does is cache EVERY directory... BUT it caches them "lazily", AND it only allows 10 d

[bug #20394] vpath directive drops entries

Follow-up Comment #4, bug #20394 (project make): Something like that could be tricky to accomplish, since make is highly recursive: when make starts checking for timestamps on files it doesn't know whether that file was found using implicit or explicit rules, etc. Plus, I think it would be even

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Follow-up Comment #19, bug #15919 (project make): I said all bugs would be reexamined before a release: I didn't say they would all be fixed before a release. Bug 3330 _was_ looked at (by me) before 3.81 was released, but I thought it was bound up with the other issues surrounding .SECONDARY and

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Follow-up Comment #20, bug #15919 (project make): OK, I went through both this bug and bug 3330 last night, and I do see the problem; thanks for all your work and the patch you provided Icarus. However, I'm not entirely sure that the way you solved this problem is the best one. Setting the stat

[bug #20394] vpath directive drops entries

Follow-up Comment #6, bug #20394 (project make): I haven't looked into it carefully, but it's not immediately clear to me that it's a simple thing to avoid the directory cache for chained/intermediate rules, vs. any other kind of rule. The disadvantage with the "is_stale" boolean is that every t

[bug #20452] Incorrect use of variable_buffer_output() in expand_deps() [file.c]

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

RE: problem

cated to the software you're trying to build. -- ----------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please r

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

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

[bug #3330] gmake -j2 does very different things to gmake -j1

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

[bug #20995] \ along multiple lines lines for '...' doesn't work

Update of bug #20995 (project make): Status:None => Not A Bug Open/Closed:Open => Closed Summary: \ along multiple lines lines for '...' doesn't work => along multiple lines li

[bug #20549] make -n doesn't work recursively

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

[bug #21376] Random Segmentation fault when run with -j n

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

[bug #21661] Make expands command-line variable defnitions after/during every command invocation

Follow-up Comment #5, bug #21661 (project make): Ah, now it's clear what the confusion is. This happens because make puts command line variable settings into the environment to be exported to the subshell. And, of course, before make can invoke a subshell it has to expand all the variables that

[bug #21661] Make expands command-line variable defnitions after/during every command invocation

Update of bug #21661 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: Dave is correct: this

[bug #22434] Consider a dependancy as target file and try to make the file

Follow-up Comment #2, bug #22434 (project make): Can you please explain clearly what exactly happens, AND what you expected to happen? I have no idea, based on the descriptions you provided, what the actual problem is. ___ Reply to this i

[bug #22198] wrong target name - possibly buffer overflow with long shell-result

Update of bug #22198 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Reply to this item at:

[bug #22379] Segmentation fault with wildcard archive rule

Follow-up Comment #2, bug #22379 (project make): No, that Debian bug is different (and that whole section of code is different in the next release of GNU make, so it's no longer needed). Please try the attached patch and see if it works. (file #15253) ___

[bug #22379] Segmentation fault with wildcard archive rule

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

[bug #22442] Old-style cancelation of implicit rules

Follow-up Comment #1, bug #22442 (project make): I'm not sure your reading of POSIX is correct. It says: - Inference rules can be redefined. A target that matches an existing inference rule shall overwrite the old inference rule. An empty rule can be created with a command consisting of sim

[bug #21823] Potential NULL pointer dereference on hash.c, hash_insert

Follow-up Comment #3, bug #21823 (project make): This is confusing, and the lack of detailed comments in hash.c doesn't help. However, I think this particular bug is impossible. Looking at the implementation of hash_find_slot(), it seems there is no way for that function to return null. So, th

[bug #21716] The following works in 3.80 but not in 3.81

Update of bug #21716 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Reply to this item at:

[bug #23468] end-of-line backslashes fails with perl (Cygwin, although I strongly believe it's general problem)

Update of bug #23468 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: As Anonymous points o

[bug #23793] MAKEFLAGS with only variable settings X=y does not work properly

Update of bug #23793 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: I don't believe this

[bug #24164] Improper Evaluation of Multiple Target rules with Static Patterns

Update of bug #24164 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: The followup comments

[bug #22923] option to prevent "interspersed" output in parallel builds

Follow-up Comment #2, bug #22923 (project make): It's not actually quite that simple, although it's do-able. Make is not a multi-threaded application, and so it cannot read from multiple streams at the same time (such as stdin and stderr, either for a single job or for multiple jobs) without a l

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

Update of bug #24486 (project make): Severity: 3 - Normal => 1 - Wish ___ Follow-up Comment #1: There is no good way to do this without completely rearchitecting how GNU make works. See: http:

[bug #24522] $(info) does not nothing

Update of bug #24522 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: The $(info) function

[bug #24723] multiple results created as a group

Follow-up Comment #2, bug #24723 (project make): Make can already do this with pattern rules. I'm assuming you mean with explicit rules? ___ Reply to this item at:

[bug #25140] Pattern-specific variable assignment behaves differently compared to normal variables

Update of bug #25140 (project make): Item Group: Bug => Enhancement ___ Follow-up Comment #1: The reason this happens is because pattern-specific variables are treated very differently from ta

[bug #25190] define expansion seems to lose the final newline

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

[bug #25578] target without target specific variable setting receives setting from unrelated target

Update of bug #25578 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: The problem is you fo

[bug #25578] target without target specific variable setting receives setting from unrelated target

Follow-up Comment #2, bug #25578 (project make): Hm. The markup seems to have swallowed my "should be" section. Also, the email seems to have deleted ALL the backslashes. Anyway, you get the idea. ___ Reply to this item at:

[bug #20495] debug version crashes on windows on close(-1)

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

[bug #25844] Spelling error in French debugging messages

Update of bug #25844 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: Hi; note that transla

[bug #26075] $(wildcard) function holds parent directories open preventing deletes

Follow-up Comment #5, bug #26075 (project make): Hm, that's interesting. There's no doubt that the directory cache causes unexpected consequences when your makefile does things "behind the scenes" that make doesn't know about (so it can't update the cache appropriately). However, this is the fi

[bug #26307] gnash in firefox high CPU

Update of bug #26307 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: I'm not sure why you'

[bug #26001] Evaluating eval expressions does not work for % type names

Update of bug #26001 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: Olexiy is mostly corr

[bug #26207] corner cases in 'override' logic for variables

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

[bug #25460] make -n better documentation

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

[bug #25694] New functions missing in quick reference

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

[bug #25697] Segmentation fault setting .DEFAULT_GOAL

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

[bug #26307] gnash in firefox high CPU

Follow-up Comment #3, bug #26307 (project make): Well, I surely don't know. GNU make is a tool used to control compiling programs. It has absolutely nothing to do with Firefox, Gnash, Red Hat, swfdec or any other codec, or anything else related even remotely to the problem you're having as far

[bug #24622] $$(eval) creating new targets causes segmentation fault

Update of bug #24622 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #3: This is a duplicate o

[bug #24588] $$(eval) with SECONDEXPANSION causes segmentation faults

Follow-up Comment #2, bug #24588 (project make): See also duplicate bug #24622 for another example. ___ Reply to this item at: ___ Message sent via/by

[bug #24488] phony targets are case insensitive with case insensitive file system

Update of bug #24488 (project make): Item Group: Bug => Enhancement ___ Follow-up Comment #1: I'm not convinced that this request is something we actually want to implement; .PHONY is not only

[bug #23986] make doesnt make cookies

Update of bug #23986 (project make): Status:None => Works for me Open/Closed:Open => Closed ___ Follow-up Comment #1: You need to get the v

[bug #24277] make leaks FDs through $(shell)

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

[bug #24251] Random error including rebuilt makefiles

Update of bug #24251 (project make): Privacy: Private => Public Open/Closed:Open => Closed ___ Reply to this item at:

[bug #24488] phony targets are case insensitive with case insensitive file system

Update of bug #24488 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Reply to this item at:

[bug #16670] Repeated backslash-escaped newlines not POSIXly replaced

Follow-up Comment #1, bug #16670 (project make): OK, the fix for this is simple enough. However, it does cause user-visible changes. It's not so much the replacing of each backslash/newline/following whitespace with a space that's the issue, it's the fact that TRAILING whitespace on the previou

[bug #16670] Repeated backslash-escaped newlines not POSIXly replaced

Follow-up Comment #2, bug #16670 (project make): Ugh. Savannah's comments kind of suck. I mean, the current behavior gives: a b and the POSIXly-correct behavior would give: a b ___ Reply to this item at:

[bug #26593] Assertion failure when building glibc with CVS make

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

[bug #24588] $$(eval) with SECONDEXPANSION causes segmentation faults

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

[bug #24655] shell_var.length isn't set causing duplicates from target_environment.

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

[bug #25712] "make update" does not work in an out-of-source-tree configuration

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

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Update of bug #15919 (project make): Status: Fixed => None Open/Closed: Closed => Open ___ Follow-up Comment #28: I've been running th

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Follow-up Comment #29, bug #15919 (project make): I took a copy of glibc 2.9 and tried building it with -j10 on my uniprocessor and on my dual core (actually single hyperthreading CPU) and it worked fine. But when I took it to a 4-way hyperthreading (8 core) system and ran with -j10 I did see so

[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1

Update of bug #15919 (project make): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #30: I debugged this and

[bug #25703] .LIBPATTERNS is not pattern dependent.

Update of bug #25703 (project make): Item Group: Bug => Enhancement ___ Follow-up Comment #1: I'm marking this as an enhancement, since the code works as designed. I agree it would be nice to

[bug #22010] The increased stack rlimit is inherited by the subprocesses to make.

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

[bug #22434] Consider a dependancy as target file and try to make the file

Update of bug #22434 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #6: This problem is happe

[bug #22442] Old-style cancelation of implicit rules

Update of bug #22442 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: Closing. Feel free t

[bug #23361] Infinite loop when including file that depends on a phony target

Update of bug #23361 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: Dave's comment is cor

[bug #23210] target/dependants with equal mtime

Update of bug #23210 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: The problem is that t

[bug #21854] Dependency to a -l to be made in a not yet existing directory doesn't match(?)

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

[bug #21823] Potential NULL pointer dereference on hash.c, hash_insert

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

  1   2   3   4   5   6   7   8   9   10   >