[bug #33125] make fails building android build environment due to memory corruption
Follow-up Comment #3, bug #33125 (project make): So I'm happy to make this change, because it does seem cleaner, but I must confess I don't understand how the original error is caused by it. The code uses isspace() to count spaces the first time through the list. isspace() matches spaces and tabs, but also form feeds, carriage-returns, etc. The second loop skips ONLY spaces and tabs. So it seems that the only possible problem here would be that the first loop counts TOO MANY words and allocates TOO MUCH memory: more than is necessary. I don't see any way for the current code to UNDER-allocate the space for the array, unless for some bizarre reason either space or TAB characters are not matched by isspace() which seems impossible. Can you provide me with a repro test case? Even just the contents of the string that were passed to the $(sort ...) function would be helpful. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33125 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33125] make fails building android build environment due to memory corruption
Follow-up Comment #4, bug #33125 (project make): I understand your puzzlement - the more I think about it the less I personally understand... I will capture the string - there is no easy test case, because the android build system isn't exactly trivial. It was only found due to corruption in free() at a much later point in time. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33125 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Make 3.82: weird circular dependency and missing $ expansion
Hi all,
First of all, thanks a lot for the good work on GNU Make!
I have a piece of Makefile that started behaving differently in the migration
from 3.81 to 3.82, and I'm tempted to call it a bug.
Using the attached Makefile (I spent quite a while to strip it down from an
Automake generated file), Make 3.81 reports:
$ make
echo accel.dat accel.dat
echo {accel.dat}
{accel.dat}
test -n accel.dat
echo accel.pdf accel.eps
Which is what I expect. But Make 3.82 reports:
$ LC_ALL=C gmake -rR
gmake: Circular accel.pdf - accel.pdf dependency dropped.
echo {}
{}
test -n
gmake: *** [accel.pdf] Error 1
I would have understood that something be reported about accel.eps, but I don't
understand what it means about accel.pdf. It would be really nice to have more
details about those circular dependencies. And see how $ is expanding to
nothing.
Weirdly enough, if I comment the document.pdf dependency, which is not
involved in plain make all, it works. If I move it, it works too. If I
compare the --print-db without-document.pdf - with-document.pdf, I can see
that things about accel.pdf differ (and $ is not defined), but it does not
help me understand what's wrong:
accel.pdf:
-# Implicit rule search has not been done.
-# File does not exist.
+# Implicit rule search has been done.
+# Implicit/static pattern stem: `accel'
+# Also makes: accel.eps
+# Modification time never checked.
# File has been updated.
-# Successfully updated.
+# Failed to be updated.
+# automatic
+# @ := accel.pdf
+# automatic
+# % :=
+# automatic
+# * := accel
+# automatic
+# + :=
+# automatic
+# | :=
+# automatic
+# :=
+# automatic
+# ^ :=
+# automatic
+# ? :=
+# variable set hash-table stats:
+# Load=8/32=25%, Rehash=0, Collisions=1/19=5%
+# recipe to execute (from `Makefile', line 9):
+ echo {$}
+ test -n $
There might be something I did not notice, I don't know. Any help would be
appreciated. Please, keep me in CC as I am not member of this list, nor
reading the newsgroup.
Makefile
Description: Binary data
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33125] make fails building android build environment due to memory corruption
Follow-up Comment #5, bug #33125 (project make): Find the captured string attached (excerpt of a debug output). If you analyze it in a hex dumper, you'll see a number of LF / space combinations. Because the splitting function does not split at LFs, it creates a number of single LF tokens split by spaces (which were skipped together as whitespace in the counting routine). (file #23336) ___ Additional Item Attachment: File name: make.dump Size:1 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?33125 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #32871] Incorrect content returned by $(value) in recipe for target specific variable
Update of bug #32871 (project make): Triage Status:None = Verified ___ Follow-up Comment #1: I agree, this is a bug. ___ Reply to this item at: http://savannah.gnu.org/bugs/?32871 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33125] make fails building android build environment due to memory corruption
Update of bug #33125 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Operating System:None = Any Fixed Release:None = CVS Triage Status:None = Verified ___ Follow-up Comment #6: I understand the problem. Fix committed. Thanks for your efforts Matthias! ___ Reply to this item at: http://savannah.gnu.org/bugs/?33125 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33125] make fails building android build environment due to memory corruption
Follow-up Comment #7, bug #33125 (project make): I also create a test case for regression testing. It's pretty trivial, I'm attaching it here. I'm just unsure in which script this should be added to. Presumably functions/sort. Please do as seems fit. (file #23337) ___ Additional Item Attachment: File name: multiline Size:0 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?33125 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #32753] struct rlimit stack_limit not declared extern in make.h
Update of bug #32753 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Component Version: CVS = 3.82 Fixed Release:None = CVS Triage Status:None = Verified ___ Follow-up Comment #1: Fixed. Thanks for the report. ___ Reply to this item at: http://savannah.gnu.org/bugs/?32753 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #33125] make fails building android build environment due to memory corruption
Follow-up Comment #8, bug #33125 (project make): I added a regression test with my fix. It won't show any difference in behavior unless you run it in valgrind or similar though. ___ Reply to this item at: http://savannah.gnu.org/bugs/?33125 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Make 3.82: weird circular dependency and missing $ expansion
On Mon, 2011-05-02 at 09:17 +0200, Akim Demaille wrote:
Using the attached Makefile (I spent quite a while to strip it down from an
Automake generated file), Make 3.81 reports:
$ make
echo accel.dat accel.dat
echo {accel.dat}
{accel.dat}
test -n accel.dat
echo accel.pdf accel.eps
Which is what I expect. But Make 3.82 reports:
$ LC_ALL=C gmake -rR
gmake: Circular accel.pdf - accel.pdf dependency dropped.
echo {}
{}
test -n
gmake: *** [accel.pdf] Error 1
I would have understood that something be reported about accel.eps,
but I don't understand what it means about accel.pdf. It would be
really nice to have more details about those circular dependencies.
And see how $ is expanding to nothing.
Weirdly enough, if I comment the document.pdf dependency, which is
not involved in plain make all, it works. If I move it, it works
too. If I compare the --print-db without-document.pdf -
with-document.pdf, I can see that things about accel.pdf differ (and
$ is not defined), but it does not help me understand what's wrong:
So, the circular dependency issue is because of this:
%.eps: %.pdf
%.eps %.pdf: %.dat
In the second rule you say that BOTH %.eps and %.pdf can be built from
%.dat, and in the first rule you say that %.eps can be built from %.pdf.
So make has two different ways to build %.eps, and one of them lists as
a prerequisite a co-target in the other rule. Make is rightly confused
here.
When make wants to build foo.eps it finds the first rule and sees that
it can build foo.eps if it can build foo.pdf, so make looks for a rule
to build foo.pdf and finds that it can build it from foo.dat... but that
rule ALSO builds foo.eps. Now make has two rules that can build foo.eps
and one of them is required to build its own prerequisite. Circular.
It all depends on the order in which make searches the rules, which is
why changing things in the makefile matters. If make finds the second
rule first then it sees it can build foo.eps and foo.pdf from foo.dat
and it's all good. No circularity.
I'm not sure about the details, and I'm not sure about why $ is empty;
that does seem like a bug.
--
---
Paul D. Smith psm...@gnu.org Find some GNU make tips at:
http://www.gnu.org http://make.mad-scientist.net
Please remain calm...I may be mad, but I am a professional. --Mad Scientist
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
[bug #32872] Inheritance of target-specific variable not always suppressed by private
Update of bug #32872 (project make): Triage Status:None = Verified ___ Follow-up Comment #1: I agree, this is a bug ___ Reply to this item at: http://savannah.gnu.org/bugs/?32872 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #32058] shortest-stem is missing from .FEATURES documentation
Update of bug #32058 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Fixed Release:None = CVS Triage Status:None = Verified ___ Follow-up Comment #1: Fixed in CVS. Thanks. ___ Reply to this item at: http://savannah.gnu.org/bugs/?32058 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #32307] Documentation does not identify versions at which new features became available
Follow-up Comment #2, bug #32307 (project make): The primary intent of the GNU make manual is to be printed into a paper book. Maybe that's anachronistic now, but I still am not terribly jazzed about the idea of sprinkling little parenthetical comments throughout the text such as (added in version 3.81) or whatever. I can see a few alternatives: 1. Make use of footnotes. I wouldn't mind having a footnote marker next to a feature that, in the footnote, said Added in GNU make 3.81 or whatever. But that might not be so convenient for online reading? 2. Add a new chapter to the GNU make manual that was essentially a shortened, cleaned up version of the NEWS file with new features only. This would collect all the information in one place. 3. Add the added in .. text using markup to ensure it's only present in the online formats, not in the printed formats. ___ Reply to this item at: http://savannah.gnu.org/bugs/?32307 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #31582] typo in documentation for $(flavor) function
Update of bug #31582 (project make): Status:None = Fixed Assigned to:None = psmith Open/Closed:Open = Closed Fixed Release:None = CVS Triage Status:None = Verified ___ Follow-up Comment #1: Fixed in CVS. Thanks. ___ Reply to this item at: http://savannah.gnu.org/bugs/?31582 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: patch to support output synchronization under -j
On Fri, 2011-04-15 at 16:57 +0300, Eli Zaretskii wrote: Date: Fri, 15 Apr 2011 12:43:53 +0100 From: Tim Murphy tnmur...@gmail.com I think it's an inevitable consequence that if you have a long-running task then the output from it won't appear until it has completely finished and you won't be able to watch the progress - in this scheme there is no way to show some of the output whilst also ensuring that it is not interspersed with output from other recipes. Well, if that's so, then this feature will be less useful than it could be, at least for me. It reminds me of my DOS days, when running a compilation command from Emacs would show me the output only when the compiler was done. I'm not happy to return to those compiling blind days. Can something be done to alleviate this? When I first read this it seemed to me that (a) there's no good way to solve this, and (b) it's not so important anyway in most builds as compiles are relatively quick. But, I've been playing with a makefile that I have, that builds a complete suite of GCC tools from scratch. I'm building them on larger systems with -j5 or -j10 (not much compared to what some are doing I realize). Sometimes these builds fail and it can be frustrating to see what part of the build is failing. But here's the thing: these makefiles are by their very nature massively recursive. Each top-level rule is an entire build of a major component like gcc, binutils, gdb, bison, etc. As far as I understand it, if I were to enable this feature then all of the output from the entire build of gcc (for example) would be collected into a file and not printed until the entire sub-make had completed. That's not very optimal. Unless I missed something? I wonder if we can figure out a way to make this work better, as Eli asked. Can we work out a way to handle normal rules (rules with + or $(MAKE)) and sub-make rules differently, so that output from normal rules wasn't collected behind a sub-make? I'm not sure I see exactly how this could work. The other thing I was thinking is that this feature might want to be enabled via a command-line argument. All the complex makefiles generated by automake, etc. for example cannot take advantage of this if you have to modify every makefile to add the special target. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
