[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #14, bug #40227 (project make): 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, an

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #13, bug #40227 (project make): I tested that patch (file #29377) with the mingw.org toolchain (gcc 4.4.0) and make still works after that, so I think it's safe to apply, provided this doesn't disturb the cygwin build... I also looked at mingw.org's mingw32/include/stdio.h and

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #12, bug #40227 (project make): 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) ___ Additi

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #11, bug #40227 (project make): Is it sufficient to add this line to output.c, like this: #ifdef WINDOWS32 # define __USE_MINGW_ANSI_STDIO 1 # include # include # include "sub_proc.h" #endif /* WINDOWS32 */ ?? Be sure to clean up any other local changes before testing. If

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #10, bug #40227 (project make): ... 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 rev

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #9, bug #40227 (project make): > (Btw, what is gnumake32.exe in your case, and how is it different from gnumake64.exe?) Sorry if that wasn't clear: gnumake32.exe was built with the 32-bits toolchain from MinGW-w64, and gnumake64.exe was built with the 64-bits toolchain from MinG

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #8, bug #40227 (project make): 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 b

[bug #40227] Various fixes for MSVC build of 4.0

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 preproces

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #6, bug #40227 (project make): 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 . I suppose this must be a relatively recent addition, as I installed that version today (major.min

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #5, bug #40227 (project make): Moreover, MinGW does not provide _vsnprintf_s (or any of the *_s functions), so I don't see how did Make compile for you after the change. It fails for me. ___ Reply to this item at:

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #4, bug #40227 (project make): 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). __

[bug #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #3, bug #40227 (project make): Actually, it seems that this output problem also affects MinGW builds, not just MSVC builds. The patch 0004-MinGW-also-needs-the-msc_vsnprintf-replacement-for-v.patch fixed it for me. As I don't have Cygwin I couldn't verify if the WINDOWS32 def

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #10, bug #40226 (project make): Actually, this issue can also be reproduced with a x64 build done using MinGW (from http://mingw-w64.sourceforge.net/). c:Workspacesrcgitmake>gnumake.exe -f Makefile.bug -Otarget Hello gnumake.exe: *** internal error: multiple --sync-mutex option