Update of bug #15919 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #30:
I debugged this and
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
Update of bug #15919 (project make):
Status: Fixed = None
Open/Closed: Closed = Open
___
Follow-up Comment #28:
I've been running the
Follow-up Comment #27, bug #15919 (project make):
Any word on a new release incorporating this fix?
It has been over a year since this bug prevented GCC
from implementing automatic dependency tracking:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01680.html
Follow-up Comment #26, bug #15919 (project make):
Knut St Osmundsen,
Your fix is similar to the one I mentioned in comment 18.
Yes, the idea is that tests pass cleanly. I just assumed that Paul tested his
fix against the test cases. I can also reproduce the problems with the
INTERMEDIATE tests
Follow-up Comment #25, bug #15919 (project make):
Is Test #9 of targets/SECONDARY supposed to run cleanly? I'm seeing a
duplicate command here (cp 2.a 2.b). I've tried current CVS head and CVS dated
2007-08-20, neither succeed, so I'm suspecting the 15th of August remake.c
change.
I see a
Follow-up Comment #24, bug #15919 (project make):
This bug affects a patch for GCC that would provide automated makefile
dependencies. It causes a lockup for make -j2 and we had to revert the
patch. Getting this patch in a stable release would be a very good thing...
Update of bug #15919 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
Follow-up Comment #23, bug #15919 (project make):
Glad its fixed. Now all I need do is work on you to get a quick release out
the door.
I no longer have access to the codebase that provoked the original bug
report, the company has gone dot bust.
Follow-up Comment #21, bug #15919 (project make):
(comment by J. David Bryan, original submitter)
I have built separate versions of make with Paul's patch from Comment #20 and
Icarus' patch from Comment #18. Both fix the problem in the original bug
submission. However, Paul's patch appears to
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
Follow-up Comment #18, bug #15919 (project make):
Sorry J David Bryan, as you say there is no obvious way to edit comments once
they have been submitted. I am just very frustrated with the current lack of
progress with GNU make, and you caught me on a bad day.
Looking over my current sources I
Follow-up Comment #17, bug #15919 (project make):
(comment by J. David Bryan, original submitter)
...they can not even spell my name correctly!
My apologies. Of course, I noted the misspelling as soon as I had posted
comment 14, but there seemed to be no way to edit a bug post after
Follow-up Comment #15, bug #15919 (project make):
If I take the current (July 4th 2007) sources of make from CVS (Paul has just
updated the license to GPL 3), and apply my patch I get the following output
$ make -j2
cp 1.a 1.b
cp 2.a 2.b
cp 1.b 1.c
cp 2.b 2.c
rm 1.b 2.b
Note that there have
Follow-up Comment #14, bug #15919 (project make):
(comment by J. David Bryan, original submitter)
The patch from Icarus Sperry does fix the original problem. However, it
appears to introduce a new one.
I have taken the original make-3.81 sources and added the patch to produce
make-381p.
Additional Item Attachment, bug #15919 (project make):
___
Reply to this item at:
http://savannah.gnu.org/bugs/?15919
___
Message sent via/by Savannah
http://savannah.gnu.org/
Follow-up Comment #13, bug #15919 (project make):
How much explanation do you want for a 1 line patch, which just initialises a
variable?
The way that make builds when it is in parallel make mode is different from
the way that it builds when it is building sequentially. The bug manifests
itself
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
Follow-up Comment #11, bug #15919 (project make):
This bug appears to be the latest incarnation of bug#3330. When that was
submitted make didn't go into an infinite loop, but the makefile that was
listed then caues make 3.81 to go into a loop.
Attached is a patch which fixes the bug, and adds a
Follow-up Comment #9, bug #15919 (project make):
I have a fix, which works with the two Makefiles that are attached to this
bug, plus my stripped down makefile, plus the real life makefile that it was
stripped from.
It also passes the make check stage.
It also fixes another old bug.
Paul, how
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
Follow-up Comment #7, bug #15919 (project make):
Here is the Makefile, stripped as much as I think I can. In particular if I
change the intermed dependency on phony to be a normal one, rather than an
order only one then everything works as I would expect. Run make clean (or
touch src) to get
Follow-up Comment #1, bug #15919 (project make):
This one looks like it's going to be a big PITA to fix.
Do you have any thoughts on why it hangs when we use the implicit rule and
does not when we use a normal one. After instantiation of the implicit rule,
the two cases should be equivalent.
URL:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=15919
Summary: Make-3.81 rc1 hangs with -j 2 but not with -j 1
Project: make
Submitted by: None
Submitted on: Mon 02/27/06 at 18:38
Severity: 3 - Normal
Follow-up Comment #2, bug #15919 (project make):
Not offhand. I haven't looked at it carefully enough. I did spend about 10
mins: just enough to verify that I can reproduce it. I also enabled
debugging and I can see that it's looping forever, not just hanging. Make
seems to think that it's
Follow-up Comment #5, bug #15919 (project make):
(comment by J. David Bryan, original submitter)
One additional characteristic: aborting make after it's hung, e.g., with
CTRL+C, and then re-running make -j 2 will complete the expected set of
actions. That is:
$ touch test.0 make -j 2
touch
Follow-up Comment #3, bug #15919 (project make):
After some more testing, it appears that removing test.3 from .SECONDARY
prevents make from hanging, not test.2.
___
Reply to this item at:
Follow-up Comment #4, bug #15919 (project make):
I tried to minimize the makefile but couldn't get any rules out without
removing buggy behavior. I could get .SECONDARY out of the way, however. The
first line in the makefile:
.SECONDARY: test.1 test.2 test.3
Can be replaced with
28 matches
Mail list logo
