Thanks for applying!

As for the /STACK patch, the issue I got in my early tries was an exception with code 0xC00000FD (STATUS_STACK_OVERFLOW). Now my problem is that I can't reproduce it anymore, even with x64 bits and the "default" /STACK.

But googling for "make 0xC00000FD" shows quite a lot of such similar issues, so I'm not (wasn't) alone with this ;-)

In my patch, 0x4000000 was indeed probably excessive and setting it to 0x400000 should be enough as it's 4 times the default. Note that if I lower this value instead (e.g. to 0x80000) I can again trigger a crash but this time with a less informative 0c0000005 exception code (STATUS_ACCESS_VIOLATION).

Yep, patch in file #29381 works for me as well
(tested with both x32 and x64 toolchains of
MinGW-w64). Thanks!

---

Googling shows that lots of projects stumble upon
this issue. MinGW-w64 chose to be compatible with
the behavior of the MS API by default, see
http://thread.gmane.org/gmane.comp.gnu.mingw.w64.general/7132/focus=7133
and this different approach is indeed a problem when
MinGW-w64 is used as a drop in replacement for MinGW32.

They have documented the vsnprintf behavior here:
http://sourceforge.net/apps/trac/mingw-w64/wiki/printf%20and%20scanf%20family

Thanks.

My debugging shows that the problem does not happen with the MinGW32 build, because vsnprintf is replaced by a conforming implementation in libmingwex.a, which is linked in by default.  (So I guess mingw.org's distribution is not as bad as it sounds.)

Therefore, only MinGW64 builds need a fix.  Please try the patch in the attachment; it is relative to stock Make 4.0.


(file #29380)

Please show me the debugging session where you saw the problem, with all the details.  I need to see that to make sure we understand the problem completely.  Just see how many different hypotheses and suggestions were offered in this discussion, and I'm sure you will understand why.

Thank you.

Yes, that would work, but the #define has to be added
much earlier, as even makeint.h includes stdio.h...

See 0004c-Ask-MinGW-w64-to-use-ANSI-style-vsnprintf.patch


(file #29377)

... and I just debugged the make built with the MinGW-w64
toolchain for x64 and without the -D__USE_MINGW_ANSI_STDIO=1
flag, the problem is indeed that vsnprintf returns -1 when the
fmtbuf is not large enough.

Also, I must have forgotten to revert my patch when I built
the 32-bits version earlier, as now I can also reproduce the
problem with also with make built with the MinGW-w64 x32
toolchain.

Bottom line: the mingw.org toolchain probably enables
the ANSI-like behavior by default, whereas the MinGW-w64
toolchains needs the -D__USE_MINGW_ANSI_STDIO=1 flag
for that.

Eli, I think that most of the GCC-on-Windows world have moved over to MinGW-w64 (for both 32bit and 64bit) and I would encourage you to do the same as you'd be in-sync with the majority of your users that way. Of course having gnumake work well on both is best but if you must pick ..

Also, you should use -D__USE_MINGW_ANSI_STDIO=1

I found the _vsnprintf_s declaration in my MinGW installation:

.../mingw64/x86_64-w64-mingw32/include/sec_api/stdio_s.h

And this gets included from <stdio.h>.
I suppose this must be a relatively recent addition,
as I installed that version today (major.minor is 3.11).

I added a version check to the patch, the numbers can be
refined to pinpoint the introduction of _vsnprintf_s, if
the approach is found to be valid and no better fix is
found.

Back to the issue itself. Here are a few quick ways to
reproduce it reliably.

First without a Makefile:

$ ./gnumake64 -f no-Makefile
gnumake64:
gnumake64: ***.  Stop.

$ ./gnumake32 -f no-Makefile
gnumake32: no-Makefile: No such file or directory
gnumake32: *** No rule to make target 'no-Makefile'.  Stop.

or with a minimal Makefile, which I inline here using --eval,
but the effect is the same with a Makefile containing that
single line:

$ ./gnumake64.exe --eval "FORCE:;" FORCE
gnumake64:

$ ./gnumake32.exe --eval "FORCE:;" FORCE
gnumake32: 'FORCE' is up to date.

Updated patch: 0004b-MinGW-also-needs-the-msc_vsnprintf-replacement-for-.patch

(file #29376)

Please provide a minimal Makefile that can be used to reproduce the problem.  Thanks.

I also don't understand why you needed to define va_copy for MinGW.  AFAICS, MinGW does have a proper definition for it (MSVC indeed doesn't, AFAIK).

Thanks for the patches!

I had stumbled on a problem in which only the first command of a recipe would be printed.  The second patch addresses that problem, as mentioned above.

Cheers,
Gerte Hoogewerf

Following the announcement, I did a checkout and attempted
to build make from the 4.0 tag, using the MSVC compilers
on Windows.

As I build preferentially from a bash shell, I tried
the "nmake -f NMakefile" way still described in the
README.W32.template file.

Unfortunately, the NMakefile.template was not complete.
This is fixed in 0001-Fix-MSVC-build-using-the-NMakefile.patch.

Second issue was detected at runtime, I had some crashes
happening in _vsnprintf. Looking at the code in output.c
it seemed that with the MSVC compiler _vsnprintf was not
supposed to be called as there's a msc_vsnprintf
replacement function. However the macro was called snprintf...
This is fixed in 0002-Fix-typo-preventing-the-msc_vsnprintf-function-to-be.patch.

Last fix, which is more a suggestion than a fix, consists
of increasing the default stack size, which proved to be
insufficient for me with a x64 build (the x86 version was
doing fine, so I suppose that the stack grows faster in the
x64 case).
See 0003-For-MSVC-build-augment-the-stack-size.patch.

With these patches (plus the fix I submitted separately in
#40226), make 4.0 seems to work like a charm on Windows
(tested with a big build started with '-j6 -Otarget' using
make.exes built with MSVC8, MSVC9, MSVC10 and MSVC11,
x64 builds).

I no longer have earlier versions of MSVC, so I don't know
if /STACK was OK there or not (I suppose it's OK).
Btw, some of the options used (/YX) are no longer valid,
others are deprecated (/GX). This results in annoying
warnings. Should I follow-up with a patch for removing them,
or is having these options still valued? (presumably they're
needed for older MSVC compilers).