[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #64806] "invalid output sync mutex" on windows
From: |
Michael Davidsaver |
Subject: |
[bug #64806] "invalid output sync mutex" on windows |
Date: |
Sun, 5 Nov 2023 13:44:43 -0500 (EST) |
Follow-up Comment #6, bug #64806 (project make):
> This bug report lacks a reproduction recipe ...
Yes, I know. Unfortunately (well, in this instance ;) ) I run Linux
exclusively on my personal systems and only interact with windows via
continuous integration builds. Troubleshooting with CI is ... tedious. If I
could reproduce this issue from a local build, I would likely be submitting a
patch instead of this confused investigation into where these two windows
builds originate. (this whole process reminds me not to take "apt-get source
make" for granted)
> ... it is not clear whether the make.exe binary which exhibits the problem
is the one from ezwinports or something else ...
I observed this issue with the make.exe distributed with the Strawberry Perl
5.38.0.1 installer. From what I have found, this binary originates as a
"personal build" by Brecht Sanders (see comment #2). So as far as I can tell,
this binary is _not_ from ezwinports.
> So more information is needed to make any progress with this bug report.
As explained above, there are limits to what additional information I can
provide.
I made a brief test on Linux to rename /usr/bin/make to something longer or
shorter. Both appear to work, and running with valgrind does not report any
errors.
This makes me wonder whether src/getopt.c is involved?
>From what I can tell from src/main.c, it looks like the pointer stored in
argv[0] is being saved prior to calling getopt_long(). Of course, there is a
lot of #ifdef in that file, which makes it difficult for me to follow.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64806>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/