Update of bug #40226 (project make):
Status:None = Fixed
Assigned to:None = psmith
Open/Closed:Open = Closed
Fixed Release:
On Sun, 2013-11-24 at 12:35 +0200, Eddy Petrișor wrote:
Since you just worked on this, and the new type overwrites in case of
repetition, does it make sense to overwrite instead of error? I think
that for profiling this type of behaviour would be better.
Sorry, but I didn't understand that.
Pe 24.11.2013 18:41, Paul Smith psm...@gnu.org a scris:
On Sun, 2013-11-24 at 12:35 +0200, Eddy Petrișor wrote:
Since you just worked on this, and the new type overwrites in case of
repetition, does it make sense to overwrite instead of error? I think
that for profiling this type of
Follow-up Comment #10, bug #40226 (project make):
Actually, this issue can also be reproduced with a x64 build done using MinGW
(from http://mingw-w64.sourceforge.net/).
c:Workspacesrcgitmakegnumake.exe -f Makefile.bug -Otarget
Hello
gnumake.exe: *** internal error: multiple --sync-mutex
Follow-up Comment #3, bug #40226 (project make):
Well, the symptom can even be reproduced without a Makefile...
$ /C/Workspace/src/git/make/WinDebug/make -Otarget -f no-Makefile
make: no-Makefile: No such file or directory
make: *** internal error: multiple --sync-mutex options. Stop.
The
Follow-up Comment #5, bug #40226 (project make):
Paul: If you already see and understand the problem, by all means take it. I
didn't yet have time to even build the release ;-).
Thanks.
___
Reply to this item at:
Follow-up Comment #6, bug #40226 (project make):
I do understand what Christian is saying, but I'm going to rewrite it out of
existence rather than fix it :-)
___
Reply to this item at:
http://savannah.gnu.org/bugs/?40226
Follow-up Comment #7, bug #40226 (project make):
Christian: Thanks for the extended explanations.
For the record: I don't see this on my system, at least not with the simple
recipe you provided. Moreover, the (second) call to `decode_switches`, after
`prepare_mutex_handle_string`, never
Follow-up Comment #8, bug #40226 (project make):
Are we going to release 4.01 soon? If not, is the problem serious enough to
fix it in the present code? Or can I safely use the Windows binary of 4.0
unaltered? (As I wrote, the problem does not happen in my usage.)
Follow-up Comment #9, bug #40226 (project make):
Eli, it looks like the problem is triggered as soon
as you have some output generated during the
`read_all_makefiles ()` phase, as it causes a call
to `prepare_mutex_handle_string ()`.
And after reading the Makefiles, `main ()` calls
Follow-up Comment #2, bug #40226 (project make):
Could you please provide a minimal Makefile and a test case to reproduce the
problem you saw? I'm sorry, but I have a difficulty understanding your
description of the bug you found in the code; hopefully a test case will help
me see the light.
11 matches
Mail list logo
