[bug #16051] Non-existent prerequisites are not included in $?
Update of bug #16051 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Fixed Release:None = CVS ___ Follow-up Comment #3: I've re-added this fix. ___ Reply to this item at: http://savannah.gnu.org/bugs/?16051 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: typos
On Sunday, 6 August, Ralf Wildenhues ([EMAIL PROTECTED]) wrote: I noticed a couple of typos in the make manual. I installed fixes for these. Thanks! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #17740] make fails without any message
Follow-up Comment #3, bug #17740 (project make): Someone who sees this problem will need to either provide a reproducible test case, or a description clear enough to allow me to create one. Based on the information in this bug I tried this: include foo.d foo.d: foo.x ; : cp $ $@ all: ; : all Then touch foo.d... but it didn't show the behavior you describe: $ touch foo.d $ make make: *** No rule to make target `foo.x', needed by `foo.d'. Stop. $ /opt/src/make/old/make-3.81/make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. ... ___ Reply to this item at: http://savannah.gnu.org/bugs/?17740 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18116] filter_out functions seems to always return an empty result
Update of bug #18116 (project make): Status:None = Not A Bug Open/Closed:Open = Closed ___ Follow-up Comment #2: As Philip says, the problem is in the makefile. If you still have issues after correcting that, post it here. Cheers! ___ Reply to this item at: http://savannah.gnu.org/bugs/?18116 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18139] make chooses wrong pattern rule
Follow-up Comment #2, bug #18139 (project make): It's not true that this is a Windows-only thing. I reproduced it on my Linux system. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18139 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18139] make chooses wrong pattern rule
Follow-up Comment #5, bug #18139 (project make): Boris, I don't see why %.o being intermediate makes a difference. Make can and does chain implicit rules. I re-read the section on chaining and I don't see anything that would contradict the basic premise of chaining, which is that the length of the chain doesn't matter, only the order in which they're defined in the makefile. Of course I could be forgetting something. I realize that just because someone works differently in 3.81 doesn't mean it's broken; however in this case I really do think that 3.80 was correct... unless, as I mentioned, I'm missing some special case. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18139 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18124] make-3.81 isn't parallel build safe
Follow-up Comment #2, bug #18124 (project make): FYI, there's some conversation on this bug over in the Red Hat Bugzilla database. I don't understand the bug and the patch doesn't enlighten me, so I'm asking for some more detail. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18124 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18139] make chooses wrong pattern rule
Follow-up Comment #8, bug #18139 (project make): Hm. Boris, is that the way it's always worked or is it something we changed recently? According to the docs as far as I can tell there's no such distinction between rules that require intermediates and those that don't. In fact, it seems pretty clear that this distinction is not intended; the docs on chaining say: There are some special implicit rules to optimize certain cases that would otherwise be handled by rule chains. For example, making `foo' from `foo.c' could be handled by compiling and linking with separate chained rules, using `foo.o' as an intermediate file. But what actually happens is that a special rule for this case does the compilation and linking with a single `cc' command. The optimized rule is used in preference to the step-by-step chain because it comes earlier in the ordering of rules. The last sentence would not be necessary if the two passes model were in place, since the no intermediates path would be chosen regardless of which order it appeared in. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18139 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1
Follow-up Comment #10, bug #15919 (project make): Hi Icarus. The easiest way to get a patch into GNU make is to attach it to the bug report and/or create a separate patch item (the first is preferred). We'll review it and apply it as-is or else discuss it with you if necessary. Also, if the patch involves significant amounts of new code you will need to assign copyright to the FSF, and your employer will also need to do so if you're employed for programming at all. If you're concerned about this contact me to discuss it. Thanks for making the effort to fix this! ___ Reply to this item at: http://savannah.gnu.org/bugs/?15919 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18173] Modification of search pattern for default make rule files
Update of bug #18173 (project make): Open/Closed:Open = Closed ___ Follow-up Comment #1: Heh. Cute :-) Feel free to use some other software to do your builds. We won't be offended. We promise. Cheers! ___ Reply to this item at: http://savannah.gnu.org/bugs/?18173 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #15919] Make-3.81 rc1 hangs with -j 2 but not with -j 1
Follow-up Comment #12, bug #15919 (project make): Thanks Icarus; that's great. Especially new testcases: that always helps. One thing: in general I like to have the ChangeLog entry describe what the change does and how it fixes things, rather than just describing the symptoms of the bug. Do you have any comments on how this change fixes the problem, or why it manifests during -j2 in particular? Thanks! ___ Reply to this item at: http://savannah.gnu.org/bugs/?15919 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18312] $(eval) within conditionals causes make to stop with syntax error
Update of bug #18312 (project make): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #1: This bug was already fixed in GNU make 3.81. Thanks for the report! ___ Reply to this item at: http://savannah.gnu.org/bugs/?18312 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #17881] Better documentation of make rules
Follow-up Comment #2, bug #17881 (project make): Actually, make _does_ guarantee that rules will be processed in left-to-right order. If you never use parallelism, you can be sure your rules will always run in that order. If you do use parallelism, though, obviously more than one of these rules will run at the same time. Even though make still starts them in left-to-right order in the makefile, it's up to your operating system to schedule the programs. In this case it's almost certain that commands to build the second target will start before the commands to build the first have completed. I'm sure you're aware of this. However, saying the order is insignificant is not exactly correct. Saying that it is unreliable during parallel builds is better. As for Howard's suggestion, that suggestion has been made before and I think it's a good one. However, it's not completely trivial to implement. For one thing, we can't afford to change the values of variables such as $, or even $^ in some cases, so make would have to keep a separate list of prereqs to run vs. prereqs used in automatic variables. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17881 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18369] pattern rules don't work with spaces in filenames
Update of bug #18369 (project make): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #1: The short answer is, GNU make doesn't handle filenames with spaces in them. Make is really not a filename manipulator, it's a string parser. And it uses whitespace to delimit strings in all aspects of its implementation and behavior. Anyway, this is a duplicate of bug #712 ___ Reply to this item at: http://savannah.gnu.org/bugs/?18369 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18396] stack size setrlimit call interacts badly with Solaris/x86 kernel bug
Update of bug #18396 (project make): Item Group: Bug = Enhancement ___ Follow-up Comment #1: If 'make' needs to allocate a large amount (megabytes) of data, it would be better to do so on the heap, both from a portability standpoint (the stack size) and from a performance standpoint (it messes up the normally good locality of stack access). Alternatively, if it must allocate on the stack, then detecting and complaining about a too-low limit would be better in my opinion than silently changing it. It's easy to uncap the stack size explicitly in build scripts and whatnot when truly necessary. Unfortunately, none of the above is true. Make needs extra stack space because it makes extensive use of the alloca() function. It does not allocate huge chunks of memory on the stack: if large amounts of memory are needed they are allocated on the stack. alloca() is used for modest-sized memory chunks, to hold filenames and smaller strings (make is, at heart, a string manipulation program). Using heap, which requires a system call to get more memory, for all of these small allocations would be much less efficient than using the stack. Not to mention the overhead of having to allocate these memory segments to be used for a short time, then freeing them again, over and over. However, because make is also very recursive, even though no single alloca() call is very large it's quite possible for the entirety of the alloca() invocations for a complex makefile to use quite a bit of stack. Of course, there's no way to determine how much stack will be used a priori, since it depends entirely on the construction of the makefile, exactly which functions are invoked in which order, and even the current state of the build (whether various targets need to be rebuilt or not). Further, there is no portable way that I'm aware of to determine how much stack is left before the program runs out. Finally, there is no way to detect an out of stack error and exit gracefully with a warning as you suggest: the behavior of alloca() is undefined if you run out of stack space (it doesn't just return NULL as malloc() etc. do). So. In order to avoid the need for extra stack in GNU make all the invocations of alloca() would need to be rewritten to use xmalloc(), and those functions would need to be changed to be careful to free all that memory whenever the function exited to avoid memory leaks... with what must certainly be a decrease in performance (although of how much we can't be sure). On the other hand, as you point out, the problem on Solaris is a bug in the kernel which you can hardly blame GNU make for. However, your point about programs invoked by make inheriting the setrlimit() is definitely something that seems problematic. Perhaps GNU make could change the stack limit back to what it was after it forks but before it execs its child. I wonder what happens if you change a limit to something too small for the current processes resources? ___ Reply to this item at: http://savannah.gnu.org/bugs/?18396 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18396] stack size setrlimit call interacts badly with Solaris/x86 kernel bug
Follow-up Comment #2, bug #18396 (project make): I wrote: if large amounts of memory are needed they are allocated on the stack Of course I meant on the _heap_ :-/. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18396 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18517] Compilation error in find_directory() in dir.c on Windows platforms
Update of bug #18517 (project make): Status:None = Later Open/Closed:Open = Closed ___ Follow-up Comment #1: Hi all. The make source code is undergoing some relatively major contortions right now as I wrestle it to an ISO C standard behavior and throw out support for KR C. Along with this is a change to use the strcache capability I added in the last release, throughout the entire codebase to greatly reduce the amount of memory used by make and hopefully, in some cases at least, increase the efficiency. The changes you see currently in CVS are minor compared to the ones I have locally in my workspace(s). The good news is that this work is almost done and as of last weekend my current version passes all the regression tests again! I'm adding some validation code and checking things with valgrind, etc. but the end appears to be in sight. The bad news is that since I don't have any Windows systems available to me to test on (ditto for VMS, Amiga, etc.) those ports have definitely rotted somewhat. I fully expect there will be many instances of this sort of problem, where strings were made constant in the POSIX port but now some love has to be applied in the other ports. I don't think it's really productive to begin this debugging until I've committed all the changes I have locally. In short, at the moment I will have to simply state that the CVS tree is known not to be stable for non-POSIX operating systems. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18517 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #18680] fix for bug#2846 does not work as expected, still hang sometimes
Update of bug #18680 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Fixed Release:None = CVS ___ Follow-up Comment #1: Doh! Silly. As a lame excuse I'll mention that the original fix was for situations where errno was not 0 _before_ invoking the macro, not where it was set to 0 inside the macro. However it should have been obvious that the latter was necessary as well. Fix applied. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18680 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #2: Only project admins can change the state of a bug (so you can't re-open it). If GCC is generated drive-lettered pathnames in a cygwin environment that is arguably a bug in GCC on Cygwin; you should report it to either or both GCC or Cygwin. However, as Eli points out there has already been a change incorporated to allow GNU make on Cygwin to handle drive letters properly (for some definition of properly). This change will be available in the next release of GNU make. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18872 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 fact it's mandated by the POSIX standard for make, which states: When an escaped newline (one preceded by a backslash) is found anywhere in the makefile except in a command line, it shall be replaced, along with any leading white space on the following line, with a single space. Since there is no limit to the length of a physical line in a makefile in GNU make, I suggest you only break physical lines at whitespace. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18561 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 this is an undocumented change in behavior. However, I think the new behavior is consistent with the documentation... if the user suggests that the file does not need to exist for inclusion via -include then it makes sense to me that a failure to build that file should not cause make to exit. I think what you really want is a solution to bug #102, so that you can have mandatory include files but not get any warnings/errors unless they really can't be built. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18641 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 process was created fro automake by Tom Tromey and it's much superior to the process in the GNU make manual. And, it doesn't suffer from this issue of invalid warnings. The solution to the problem is just as described in bug #102; the message about makefiles not being rebuildable would be deferred until after the makefile has tried to be created and only printed if it couldn't be. I don't see any issue with backward compatibility in this. I took a very quick look at the SF page but there wasn't much there: no homepage, no docs that I could find, etc. If you want to discuss it, probably the help-make@gnu.org mailing list is the best place. Cheers! ___ Reply to this item at: http://savannah.gnu.org/bugs/?18641 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 the point of obscuring its intent. What the docs should say is: any included makefile (by either include or -include), whether it exists or not, will be considered a target and make will try to update it. If the makefile exists and the update succeeds (this includes the case where make does not have any rules to update the makefile), then it is included. If the update of the makefile fails then if it was include'd, (although I think it might be a duplicmake will fail; if it was -include'd, make will ignore the error and continue on. An update failing can be because the makefile does not exist and make has no rule to build it; or because the rules needed to build the makefile (or any of its prerequisites of course) failed--regardless of whether the makefile exists or not. I'm changing this to a doc bug. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18963 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 not reproducible, and doesn't even make sense. There's nothing in the code that would treat any of these values specially. You must have some issue in your makefile which is causing this; please attach a sample makefile (don't cut and paste the contents as that will change them). Also always provide info on the operating system you're using and what version it is, etc. I'm closing this bug for now; if you have more information please add it and I'll re-open. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19015 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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, an undefined origin means that the variable is not known to make (when make looks it up in its internal tables, nothing is found). Obviously, once you export or unexport a variable, it has to be added to make's internal tables so make can remember that you marked it as exported or unexported... so then it's no longer undefined. I can understand your point, however. I've marked this as an enhancement request. It shouldn't be too difficult to implement: a new origin value for undefined would need to be added, which is easy... but then all the places the origin is used would need to be examined to determine if or how they should react when a variable in this new state is found. This would also allow us to create a way to undefine a variable; currently once a variable is defined it can never go back to the undefined state again. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18995 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 replacement for SystemV make. GNU make is an implementation of POSIX-standard make, with many (MANY) extensions. Just because your makefile works with Solaris and HP make does not automatically mean it will work with GNU make--it all depends on what SystemV special features you may be using, etc. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19035 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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. Double colon implicit rules have a different meaning than double-colon explicit rules. See the section Match-Anything Pattern Rules in the GNU make manual. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19183 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 unpleasant; however I don't see anything make can do about it. Eval works by first expanding its argument(s), then evaluating the result. In your example, after the expansion of $(Y) make sees: ifeq (1,1) B := X\ endif and there's no possible way that the eval can know that this backslash was originally contained in the variable A, rather than being written directly by you. The only solution to this is for YOU to be more cautious about when you allow variables to expand. If you defer the expansion of A so that it's done by the eval itself instead of being done up front before eval is invoked, then you'll get the behavior you want; change the definition of Y as follows: define Y ifeq (1,1) B := $$(A) endif endef By using $$(A), it won't expand during the expansion of Y, and eval will see this: ifeq (1,1) B := $(A) endif with no backslash... THEN when eval evaluates this IT will expand A and set B to the right value (X\). For your real life example this would translate to: define $(COMP)_CUSTOM_WX_TARGET ifneq ($(filter bcb%,$(TOOLSET)),) $(1): export PATH := $(BCCDIR)bin;$$(PATH) endif endef Although, as a general rule, I find it best to defer expansion of ALL variables other than those that require it (typically as part of a call), so the above might be more safely written: define $(COMP)_CUSTOM_WX_TARGET ifneq ($$(filter bcb%,$$(TOOLSET)),) $(1): export PATH := $$(BCCDIR)bin;$$(PATH) endif endef I'm closing this for now but if anyone has any ideas on how to make this work better please add a note or bring it up on the mailing lists. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19236 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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, and is not related to parallel make; you're using VPATH incorrectly. Paul's Third Rule of Makefiles states that you should never use VPATH to find TARGETS. VPATH is only usable to find SOURCES. Read my discussion of VPATH here to learn why your example works the way it does: http://make.paulandlesley.org/vpath.html You're also violating Paul's Second Rule of Makefiles, in this rule: .cc.o : $(CXX) $(CXX_FLAGS) $(INCLUDES) -c -o $(DEST)/$@ $ ANY time you see a rule where it's constructing a target that is not EXACTLY $@, you know the rule is incorrect. Here you're building $(DEST)/$@, not $@, so your rule is incorrect. If you rework your example to use VPATH, etc. properly and still see problems, please file a note with this bug and we can re-open it. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19309 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 is documented to work; from the GNU make manual, section Variables from the Environment: When `make' runs a command script, variables defined in the makefile are placed into the environment of that command. This allows you to pass values to sub-`make' invocations (*note Recursive Use of `make': Recursion.). By default, only variables that came from the environment or the command line are passed to recursive invocations. You can use the `export' directive to pass other variables. *Note Communicating Variables to a Sub-`make': Variables/Recursion, for full details. With the single exception of the SHELL variable, all environment variables are imported as make variables when make starts, and automatically marked as exported so that when make runs a command their current values will be exported into the environment of the command. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19626 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-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 that uses objective-C needs to be changed, but the same is true for any number of other languages that make doesn't provide default rules for. Further, even if we do change this for the next release of GNU make that won't be out for some months, then it will be many months more before that version is considered wide spread (I know of distros that still ship GNU make 3.79.1, and MANY that still use 3.80 more than a year after 3.81 was released). And finally, of course, requiring default rules just means makefiles are even more tightly tied to GNU make (since no other make provides these default rules as far as I know). ___ Reply to this item at: http://savannah.gnu.org/bugs/?16389 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?19656 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 well: A target is considered out-of-date if it is older than any of its prerequisites or if it does not exist. And also: The make utility examines time relationships and shall update those derived files (called targets) that have modified times earlier than the modified times of the files (called prerequisites) from which they are derived. It's also incorrect to classify this behavior as a recent change in GNU make; GNU make has always worked this way. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19448 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 foo 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 wild, because it immediately hit build environments where many hundreds or even thousands of files were included... and the re-exec of make failed because the environment was not sufficiently large to be able to pass all those options through exec! Considering there is really no way to ensure that you have enough space for all possible uses, I took that code back out and reverted to the original (and still current) behavior. However, recently a new suggestion has been made which would enhance make to understand @-files, which are apparently becoming more common even on some UNIX platforms as a way to pass large numbers of arguments. If that feature was added to GNU make then make could take advantage of it to propagate the -W flags in a way that wouldn't blow out the environment. See patch #5809 ___ Reply to this item at: http://savannah.gnu.org/bugs/?19448 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?19035 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = Any Fixed Release:None = CVS ___ Follow-up Comment #3: I added a new debug statement to the basic debug output that specifies where the command script was found for a given target, when make starts to build that target. For commands found in a makefile you get: Invoking commands from makefile:lineno to update target `target'. For builtin commands, you get: Invoking builtin commands to update target `target'. ___ Reply to this item at: http://savannah.gnu.org/bugs/?18617 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19900 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 summer. I have high hopes that it will be flexible and powerful enough to provide all the functionality people need to implement various algorithms including things like comparing stored stat(2) info as well as .KEEP_STATE capabilities. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19975 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #4: OK, I found it. I'm still not 100% sure why it makes a difference between parallel and non-parallel jobs but I think I understand it. The attached patch definitely seems to fix the problem. (file #13043) ___ Additional Item Attachment: File name: 20033.diff Size:1 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?20033 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #20067] Unescaped meta characters in makefile database outputs
Update of bug #20067 (project make): Item Group: Bug = Enhancement ___ Reply to this item at: http://savannah.gnu.org/bugs/?20067 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #1: 3.5 The Variable `MAKEFILE_LIST' Already fixed (bug #16304) 3.9 How `make' Reads a Makefile Good catch; fixed this one. 4.2 Rule Syntax Fixed a while ago. 4.9 Special Built-in Target Names Fixed a few weeks ago. Thanks for the report! ___ Reply to this item at: http://savannah.gnu.org/bugs/?20018 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 appeared in the makefile. I'll look at it more closely; there might be a way to get back the original info. ___ Reply to this item at: http://savannah.gnu.org/bugs/?20133 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 directories to be open at any one time. Basically, when make wants to check a file in a directory it opens the directory for reading and looks for that file. As it reads the directory it caches the contents. Once the file is found, it leaves the directory open but stops reading. If make looks for another file in that directory and it's not in the cache, make continues reading (and caching) where it left off. If it gets to the end of the directory it closes the directory. In order to avoid too many directories being open by make at one time, if make gets to a point where more than 10 directories are open, it will completely read and cache the current (latest) directory, then close it. The issue of make's caching is well-known (see bug #443 for example). In your case it takes an odd twist but this is definitely the issue. A completely correctly-written makefile shouldn't run across cache problems, but I recognize there are situations where it's not possible to write that makefile. However, in your case I think you can do what you want. Change your makefile like this: LIBS := $(patsubst %,-l%,$(SUBDIRS)) LIBTARGETS := $(foreach L,$(LIBS),$(L)/lib$(L).a) all: $(TARGET) $(TARGET): $(LIBTARGETS) $(CC) -o $@ $(LIBDIRS) $(LIBS) $(LIBTARGETS): FORCE $(MAKE) -w -C $(@D) -f Makefile $(MAKECMDGOALS) FORCE: This has some other advantages over the method you were using (for one thing, your example does not work properly if any of the sub-makes fail). ___ Reply to this item at: http://savannah.gnu.org/bugs/?20394 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 more confusing to have some kinds of targets (implicit) behave unexpectedly while others (explicit) behaved as expected, but more slowly. To fix this problem we need to add a way to determine if the cache is stale. My idea on how to do this is for make to keep a counter that is incremented every time make invokes a subprocess. Or maybe, from a correctness point of view, it should be updated every time a subprocess _finishes_. Then when a directory was cached it would store the current value of that counter. The next time the cached data was consulted, if the current counter was greater than the stored counter the cache would be considered stale and new data would be read. This would significantly reduce the efficiency of the cache, but it would increase correctness and the cache would still be useful while make is looking for things to build--for situations where there's very little or nothing to do the cache would still be a big win. ___ Reply to this item at: http://savannah.gnu.org/bugs/?20394 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 state of the intermediate file to cs_not_started seems incorrect to me; it does seem to solve the problem, at least for the cases described in these bug reports, but it means that after we're done the intermediate file is marked as not started which I'm not sure is correct. Also, I do see J. David's issue with a pattern rule invoked twice on my vanilla CVS head tree with the original patch applied. I have an alternative change that feels more correct: after all the prereqs of the intermediate file are done, if we don't need to make the intermediate file then we call notice_finished_file() on it to complete it. With this patch, J. David's example works correctly as do the other examples in both this bug and bug 3330. I attach the code change only here: obviously the real fix will involve change logs, test cases, etc. I think your idea of having a timeout is a good one, Icarus, but I think I will make it general so that EVERY test we run has a timeout; these can be modified on a per test basis of course. Please let me know whether this patch solves all the issues you have in real life and any other comments you have. (file #13283) ___ Additional Item Attachment: ___ Reply to this item at: http://savannah.gnu.org/bugs/?15919 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 time something goes stale you have to walk through the entire cache and reset all the boolean values. If you use a counter then you don't have to touch anything in the cache until and unless you need to look at that cached data, then you compare (and update) the counter kept with that set of data. It may be that our caches are not large enough to make a difference, practically speaking; I'm not sure. ___ Reply to this item at: http://savannah.gnu.org/bugs/?20394 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #1: You're absolutely right. Good catch. One note: your fix for the second case is incorrect; it should be: d-name = strcache_add_len (variable_buffer, o - variable_buffer); Patch attached. (file #13338) ___ Additional Item Attachment: ___ Reply to this item at: http://savannah.gnu.org/bugs/?20452 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
RE: problem
Gupta, Sonia (Product Engineering Services, Mumbai) writes: While doing qmake calculator.pro we get an error Qfile:: file not specified.atleast 100 times. Can you tell us why is that. No. This list is for discussion of bugs and issues with building and using GNU make itself. First, unless you made a typo, you are using qmake, which is not GNU make. Second, even if you're really using GNU make your problem is with the code you're trying to build (missing headers, librarires, etc.) and not with GNU make itself. You'll have to ask on a mailing list dedicated 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 remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #22: OK, I did a bunch more testing and created test cases to cover all the aspects of this bug reported here and in 3330. Fix committed. Thanks to both of you for your work on this issue. ___ Reply to this item at: http://savannah.gnu.org/bugs/?15919 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #4: OK, committed a fix for this (and bug #15919), plus test cases. Thanks to Icarus for all his work on this. ___ Reply to this item at: http://savannah.gnu.org/bugs/?3330 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 lines for '...' doesn't work ___ Follow-up Comment #1: Hi Frank; the 3.81 behavior is correct. The POSIX spec for make says: When an escaped newline is found in a command line in a makefile, the command line shall contain the backslash, the newline, and the next line, except that the first character of the next line shall not be included if it is a tab. See the GNU make manual subsection Splitting Command Lines (node Splitting Lines), in section Command Syntax, chapter Writing the Commands in Rules, for details. We are discussing adding a .ONESHELL feature for the next version of GNU make; if we do that then this could be used to get the kind of behavior you're looking for. ___ Reply to this item at: http://savannah.gnu.org/bugs/?20995 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 of bug #20033. There's a patch attached to that bug. I only was able to determine this by looking at the stack trace you provided to the mailing list; when reporting bugs please remember to add in stack traces, etc. wherever possible. Cheers. ___ Reply to this item at: http://savannah.gnu.org/bugs/?21376 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 are to be exported. See http://www.gnu.org/software/make/manual/html_node/Variables_002fRecursion.html#Variables_002fRecursion You can avoid this by adding an explicit unexport var to your makefile. ___ Reply to this item at: http://savannah.gnu.org/bugs/?21661 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?22198 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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) ___ Additional Item Attachment: File name: p.diff Size:0 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?22379 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #3: I'm closing this as the bug is fixed in my testing. ___ Reply to this item at: http://savannah.gnu.org/bugs/?22379 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 simply a semicolon (that is, the rule still exists and is found during inference rule search, but since it is empty, execution has no effect). The empty rule can also be formatted as follows: rule: ; where zero or more blanks separate the colon and semicolon. - To me this seems to reaffirm make's behavior: the rule exists and is found during inference rule search, but execution has no effect. I think you can get the behavior you want by some combination of removing suffixes in .SUFFIXES, and perhaps changing the order in which they appear. If not can you provide a simple test case? You can dummy out the actual compilation with touch and cp etc. commands. ___ Reply to this item at: http://savannah.gnu.org/bugs/?22442 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?21716 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 is a bug. The GNU make manual says: `MAKEFLAGS' begins with a hyphen only when it begins with an option that has no single-letter version, such as `--warn-undefined-variables' In general, it's not correct to put $(MAKEFLAGS) in a recipe line when invoking a sub-make. MAKEFLAGS is intended to be passed to the sub-make through the environment, not the command line, and this will happen automatically for you all the time. Sub-makes should be invoked as just $(MAKE), with no $(MAKEFLAGS). For more information, see section Communicating Options to a Sub-make in the GNU make manual. ___ Reply to this item at: http://savannah.gnu.org/bugs/?23793 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 are correct and this is expected and documented behavior; I'm closing this as not a bug. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24164 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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://www.mail-archive.com/[EMAIL PROTECTED]/msg06212.html for example. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24486 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 was added in GNU make 3.81. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24522 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?24723 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 target-specific variables, internally. With target-specific variables there is an actual target and the variables are kept and expanded with reference to that target. Since an explicit target is stated, even if that target is not known already we can create one to hook these variables to when the makefile is read in. With pattern-specific variables there is no known target at the time the pattern variable is defined, so pattern variables are simply kept as a list of potential variable settings. They are not resolved when the makefile is read in, because there's no target to hook them to. They are resolved when the target is to be built: at that time all the pattern-specific variable patterns are matched, one at a time, to the target and if it matches the expansion occurs. Obviously that comes in the second phase of the build, after the makefiles have all been read in (and, in your example, the variable $(v) has been reset). It's potentially conceivable that all the pattern-specific variables with the exact same pattern could be treated as target-specific variables are, and the variable settings for that pattern can be combined into a group. However, even that would not be 100% accurate; suppose you had two patterns %.bar and foo%.bar, then with a target of foobaz.bar you could reasonably expect the pattern-specific variables to be handled as if they were target-specific variables for foobaz.bar... but there's really no way to do that. This behavior is actually quite tricky to get right: combining :=, +=, inheritance, etc. I'll leave this open as an enhancement request. ___ Reply to this item at: http://savannah.gnu.org/bugs/?25140 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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. See the GNU make manual, section Defining Variables Verbatim, where it says: The value in an ordinary assignment cannot contain a newline; but the newlines that separate the lines of the value in a `define' become part of the variable's value (_except for the final newline which precedes the `endef' and is not considered part of the value_). Note the final parenthetical comment (highlight added). ___ Reply to this item at: http://savannah.gnu.org/bugs/?25190 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 forgot a backslash in the programs/retriever/rules.mk file, so the variable assignment is not attached to the target but is rather just a normal assignment. lib/libOPSCarchretrhook.$(SL): LINK_LIBS:= OPSCcomm OPSCbase errors Should be: lib/libOPSCarchretrhook.$(SL): LINK_LIBS:= OPSCcomm OPSCbase errors You can find out where variables were assigned very easily by running make with the -p option; this will print the entire database make used, and the filename/linenumber where each was defined in the makefile. ___ Reply to this item at: http://savannah.gnu.org/bugs/?25578 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?25578 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Reply to this item at: http://savannah.gnu.org/bugs/?20495 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 translation is not handled by the GNU make team, but rather by the GNU translation team. There's not much we can do to fix this problem, because we dynamically download the latest translation from the GNU translation team every time we build a new release; the translations are not kept in the GNU make source tree so we can't keep updates. You need to contact the translation team for the language you're concerned about. You can start here: http://translationproject.org/domain/make.html to find the right team. I'm closing this bug in Savannah, but feel free to reopen if you have troubles. ___ Reply to this item at: http://savannah.gnu.org/bugs/?25844 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 first time I've ever heard the assertion that it is actually slower than no cache at any time, much less on average, or by magnitudes. I'm not saying you're wrong, because I've never tested it myself. But, do you have any hard data to prove this assertion? ___ Reply to this item at: http://savannah.gnu.org/bugs/?26075 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #1: The initial behavior is indeed correct, as Manoj has explained. Once a variable is elevated to the status of override, which is the highest priority a variable can have, any subsequent assignment or append to that variable which is of a lower priority will be ignored. You can continue to append to that variable, or even change its value, but only if you precede the subsequent assignments with override as well. I added some text to the GNU make manual that might make this clearer. As for the other effects you observed, those are due to a real bug in the system. I've attached a patch here which I will be committing as soon as Savannah's source control systems come back up. (file #18213) ___ Additional Item Attachment: File name: read.diff Size:0 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?26207 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #2: Modified the GNU make manual and man pages to give appropriate caveats. ___ Reply to this item at: http://savannah.gnu.org/bugs/?25460 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #1: Fixed in source code. Thanks. ___ Reply to this item at: http://savannah.gnu.org/bugs/?25694 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #2: The issue here is by doing this: .DEFAULT_GOAL := $(myDefaultGoal) #restore the previous default rule you are actually setting the .DEFAULT_GOAL variable to contain a single space rather than an empty string--make always preserves all TRAILING whitespace after a value, so any space between the value and a comment, for example, is included in the value. Obviously make should not crash even so, and I've fixed this bug; now you'll get: make: *** No targets. Stop. I also noticed make wasn't expanding this variable before use, which is wrong. Fixed that too. ___ Reply to this item at: http://savannah.gnu.org/bugs/?25697 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 as I can determine. I recommend using Google to search for something like gnash bug reporting or similar. ___ Reply to this item at: http://savannah.gnu.org/bugs/?26307 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?24588 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 used for completely phony targets (where using case-sensitive matching would make sense), it's also used to mark real files that could appear on the filesystem as always rebuilt for various reasons. In this case you would want them to be treated case-insensitively. Even if we wanted to do this, there's no easy way to do it: the --enable-case-insensitive flag is a _compile-time_ flag which changes the entire behavior of make at a code level. There is no facility in the codebase today to track case-insensitive flags on a per file target. As for special targets not being case-insensitive, that is not a bug. Case-insensitivity does not apply to special documented targets like .PHONY etc. I'm marking this as Enhancement right now but I'm inclined to close it as Not a Bug. Comments requested. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24488 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 version of Linux installed in the Ronco Auto-Kitchen 9000, then drop to the command line and run make cookies from there. ___ Reply to this item at: http://savannah.gnu.org/bugs/?23986 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #2: Thanks for the report. I ended up fixing this slightly differently, by adding a test for fileno() into configure.in and running CLOSE_ON_EXEC() on fileno() of the FILE*. Checking /proc/self/fd in a $(shell ...) confirms this works. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24277 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?24251 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?24488 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 previous line is no longer condensed. The current behavior basically condenses ALL whitespace starting with the last non-whitespace character on the previous line and going until the next non-whitespace character (where backslash/newline are considered whitespace) and replaces it with a single space. So, in the current version of make this: FOO = a b Gives a value of $(FOO) that is a b. In the new behavior this would give a b, because the trailing whitespace on the previous line is preserved, plus one extra space for the backslash/newline/following whitespace. ___ Reply to this item at: http://savannah.gnu.org/bugs/?16670 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?16670 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #3: Yes, this is bad. The fix is simple as you suggest. ___ Reply to this item at: http://savannah.gnu.org/bugs/?26593 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #3: Fixed using a change almost identical to yours. Thanks! ___ Reply to this item at: http://savannah.gnu.org/bugs/?24588 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #1: I can't reproduce the problem (I don't get failures in the SHELL unit tests) but I agree that the change you proposed is necessary and I've made it in the source code. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24655 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #1: This is not officially supported but I made changes to allow it to work. ___ Reply to this item at: http://savannah.gnu.org/bugs/?25712 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 the unit tests for months and never had a failure in targets/SECONDARY. I still don't, using the latest downloaded code (there is an odd issue with variable/SHELL that I don't see at home but do see here as a result of my checkins over the last week; I think the test is wrong bug I don't understand why I didn't see this at home). I tried to reproduce the INTERMEDIATE file failure by editing the INTERMEDIATE test file and adding -j2 and -j5 to the run_make_with_options invocations for test 3, 4, and 5 and I got correct behavior there as well; no errors reported. I wonder if this is somehow behaving differently on Linux? ___ Reply to this item at: http://savannah.gnu.org/bugs/?15919 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 some bad behavior: not hangs though. Instead it seemed the same recipe was being invoked 1 time which eventually caused the build system to fail, because at the end of the recipe there's a job that removes a file. If the multiple recipes run in the right way then one of the instances removes that file before the next one gets a chance to use it. I'll look at this. ___ Reply to this item at: http://savannah.gnu.org/bugs/?15919 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 applied the change Knut suggested; after this glibc with make -j10 builds without error. ___ Reply to this item at: http://savannah.gnu.org/bugs/?15919 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 allows LIBPATTERNS (and VPATH!) to use target-specific and pattern-specific values. Right now, though, we don't set up the variable sets properly before doing the lookups for this to happen. ___ Reply to this item at: http://savannah.gnu.org/bugs/?25703 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #1: Fixed; if I change the stack limit I remember the original value and reset it after forking for a job. I also added ulimit to the list of shell commands so make will choose the slow path when ulimit is present. ___ Reply to this item at: http://savannah.gnu.org/bugs/?22010 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 happening because in your Viewer.cpp file you say: #include Viewer Because of this, when automake generates the automated prerequisites for the .o file (in src/.deps/) one of the prerequisites is the simple word Viewer. When make sees that prerequisite, it tries to build it. Make has no idea that you really mean a header file here that it can't see: it looks for a file Viewer and one doesn't exist, so it tries to build it. Make has a built-in rule that says you can build any program FOO from FOO.cpp, and since it wants to build Viewer and it finds a Viewer.cpp... voila. It tries to compile it and fails. This may or may not be a bug, but if it is it's a problem in automake's automated dependency generation, not GNU make. ___ Reply to this item at: http://savannah.gnu.org/bugs/?22434 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 to re-open if you have more details. But, if you're just looking for help then the help-m...@gnu.org mailing list might be more productive. ___ Reply to this item at: http://savannah.gnu.org/bugs/?22442 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 correct. This is behaving as expected. Not ideally, but as expected. Since make re-execs itself it's actually quite difficult to know what files were already built by a previous incarnation. For a while I had a feature where the re-exec would add -o options for all makefiles rebuilt so that the next invocation would not try to rebuild them. However, some people rely on this behavior AND it also caused problems with makefiles that have lots of included files: the re-exec was failing due to running out of environment space. ___ Reply to this item at: http://savannah.gnu.org/bugs/?23361 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 the mtime of objects in an archive is based on the format of the archive. There's not much we can do about this: it is what it is. If the timestamp of the objects in the archive is 1 second granularity, then that's all we have. ___ Reply to this item at: http://savannah.gnu.org/bugs/?23210 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #21854] Dependency to a -llibname 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 ___ Follow-up Comment #2: This bug has already been fixed in the latest CVS version of make. ___ Reply to this item at: http://savannah.gnu.org/bugs/?21854 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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:None = CVS ___ Follow-up Comment #4: Fixed by removing the confusing test. ___ Reply to this item at: http://savannah.gnu.org/bugs/?21823 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #21198] Wrong order of prerequisites with 3.81/CVS
Update of bug #21198 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Component Version: CVS = 3.81 Fixed Release:None = CVS ___ Follow-up Comment #3: Fixed. This is gross: the way we construct then reverse the prereq list leads to some hackery due to second expansion, and the hackery was incomplete such that this bug occurred. ___ Reply to this item at: http://savannah.gnu.org/bugs/?21198 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #24622] $$(eval) creating new targets causes segmentation fault
Update of bug #24622 (project make): Status: Duplicate = Fixed Assigned to:None = psmith Fixed Release:None = CVS ___ Follow-up Comment #5: Oops. I had a change I was testing that fixed this bug but took it out. Added it back now and this is really fixed (reports an error but does not segfault). ___ Reply to this item at: http://savannah.gnu.org/bugs/?24622 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
