[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 32-b

[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 #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 h

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

URL: 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 #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 #40227] Various fixes for MSVC build of 4.0

Follow-up Comment #20, bug #40227 (project make): Thanks for applying! As for the /STACK patch, the issue I got in my early tries was an exception with code 0xC0FD (STATUS_STACK_OVERFLOW). Now my problem is that I can't reproduce it anymore, even with x64 bits and the "default" /STACK. But g

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

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

[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.txtSize:13

[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 #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 #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 #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

[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 `decode_env

[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 rea

[bug #40226] Weird failure on Windows with OUTPUT_SYNC_TARGET

Follow-up Comment #1, bug #40226 (project make): Second thought... I see now where the bug is coming from. Some use cases for the stringlist imply it's handled as a null-terminated array: for (pp=output_sync_option->list; *pp; ++pp) Some others iterate up to idx: for (idx = 1; idx <

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

Additional Item Attachment, bug #40227 (project make): File name: 0001-Fix-MSVC-build-using-the-NMakefile.patch Size:1 KB ___ Reply to this item at: ___

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

URL: Summary: Various fixes for MSVC build of 4.0 Project: make Submitted by: cboos Submitted on: Wed 09 Oct 2013 11:42:35 PM GMT Severity: 3 - Normal Item Group: Build/I