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/