[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #2, bug #40241 (project make): Something like: foo: /usr/bin/touch $@ fails because /usr/bin/touch doesn't exist in the filesystem (so, to answer your question, the former). ___ Reply to this item at:

[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 #40241] CreateProcess failure with unixy paths

Follow-up Comment #1, bug #40241 (project make): Can you show a Makefile recipe that fails in this way? Does it fail because /usr/bin/install is actually mapped to some directory like C:\MSYS\bin, and /usr/bin does not really exist in the filesystem? Or does it fail because you think CreateProce

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

Follow-up Comment #17, bug #40227 (project make): Sorry, wrong patch. Please use this one instead. (file #29381) ___ Additional Item Attachment: File name: vsnprintf2.dif Size:0 KB __

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

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

[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