[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #3, bug #40226 (project make): Well, the symptom can even be reproduced without a Makefile... $ /C/Workspace/src/git/make/WinDebug/make -Otarget -f no-Makefile make: no-Makefile: No such file or directory make: *** internal error: multiple --sync-mutex options. Stop. The

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #9, bug #40226 (project make): Eli, it looks like the problem is triggered as soon as you have some output generated during the `read_all_makefiles ()` phase, as it causes a call to `prepare_mutex_handle_string ()`. And after reading the Makefiles, `main ()` calls

[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:Workspacesrcgitmakegnumake.exe -f Makefile.bug -Otarget Hello gnumake.exe: *** internal error: multiple --sync-mutex

[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

[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 stdio.h. I suppose this must be a relatively recent addition, as I installed that version today

[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

[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

[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) ___

[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 #15, bug #40227 (project make): As requested, 3 debugging sessions that recap the whole problem with vsnprintf for MinGW-w64. (file #29378) ___ Additional Item Attachment: File name: gdb-trace-vsnprintf.txt

[bug #41730] Make doesn't show text for error messages when using the Microsoft C runtime

Follow-up Comment #1, bug #41730 (project make): Duplicate of bug #40227 which is already fixed in git. You'll soon realize that there are some other issues with stock 4.0 when it's built with msvc, so better go with the latest in git ;-)

[bug #43887] shell function blocks for x64 builds with MSVC compiler

URL: http://savannah.gnu.org/bugs/?43887 Summary: shell function blocks for x64 builds with MSVC compiler Project: make Submitted by: cboos Submitted on: Thu 25 Dec 2014 05:55:11 PM GMT Severity: 3 - Normal

[bug #44308] combination of $(call ...) and $(value ...) functions

Follow-up Comment #4, bug #44308 (project make): Your example reminded me similar constructions I use a lot in my own Makefiles. I use a technique which I call the eval/value style which allows me to generate parametric Make code without having to deal with annoying levels of $ quoting. Here's

[bug #46077] SHELL process handling does not work under Windows 10 in x64 build -> endless waiting

Follow-up Comment #2, bug #46077 (project make): Eli, I just saw that make-4.1-2-w32-src.zip from your ezwinports doesn't have that fix. Any chance for a 4.2pre build? ___ Reply to this item at:

[bug #46077] SHELL process handling does not work under Windows 10 in x64 build -> endless waiting

Follow-up Comment #4, bug #46077 (project make): Oh right, #43887 was indeed about a 64-bits (msvc) build. As sometimes my ez-make-4.1 builds hang with -j, I thought it could be because of this reason... but it could well be something else. I'll try to have a closer look by rebuilding 4.1-2