Follow-up Comment #5, bug#63840 (group make):
> Sorry for the delay in examining this bug.
Thank you for looking at this.
...
> However, I tend to agree with you that this is perhaps too much "inside
baseball" for the default behavior.
i also think, this is too much to be useful. E.g. in
Follow-up Comment #34, bug#64806 (group make):
That weird problem is with a particular build of Windows port of GNU Make, and
it is not clear to me on what OS the error was seem.
But yes, it sounds like it's a separate issue.
___
Reply
Follow-up Comment #4, bug#63840 (group make):
Sorry for the delay in examining this bug. I understand what you are saying.
A counter-argument would be that if you wanted to use "-r" and also provide
match-anything rules, that you should also be assigning proper suffixes via
".SUFFIXES" to
Follow-up Comment #33, bug#64806 (group make):
The original problem statement by Michael Davidsaver (comment #1 - comment
#11) suggested some apparent corruption of a command line argument that
carries the mutex handle number:
> make: *** invalid output sync mutex: �*V8�. Stop.
I am afraid,
Follow-up Comment #32, bug#64806 (group make):
I don't think I understand what you mean by "change management aspect", and
why the behavior discussed here doesn't have much to do with the original
problem report. Please elaborate.
___
Follow-up Comment #31, bug#64806 (group make):
Indeed, probably the smallest change would be just _not_ closing the handle in
_osync_clear()_ [w32os.c] i.e., relying on Windows to auto-close the handle
upon process termination, without any other change in the control flow (this
is the workaround
