Follow-up Comment #7, bug #40227 (project make):
You are using MinGW64. I use MinGW32 from mingw.org, a different distribution
with a different set of headers.
The tests you propose on __MINGW32_MAJOR_VERSION etc. will not distinguish
between MinGW64 and MinGW32. So we need some other preprocessor symbols.
More importantly, I don't see the problems you report:
D:\gnu\make-4.0>gnumake -f no-Makefile
gnumake: no-Makefile: No such file or directory
gnumake: *** No rule to make target 'no-Makefile'. Stop
See: no problem. (Btw, what is gnumake32.exe in your case, and how is it
different from gnumake64.exe?)
Can you please step with a debugger into the offending code, and actually show
me what is failing there, and why?
Anyway, the only problem I know of with vsnprintf provided by the MS runtime
is that it returns -1 when there's not enough space in the buffer, instead
behaving like ANSI requires. If that is the problem (but I still want to see
the code that fails due to this), it should be easy to fix with either (a) a
trivial one-liner that handles a negative return value as a value larger than
the buffer, or (b) by compiling Make with -D__USE_MINGW_ANSI_STDIO, which
causes these functions to be replaced with ANSI-compatible versions supplied
by MinGW.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?40227>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
