[bug #37648] [Regression from 3.81] Cannot build projects having files with German/French/other specific characters

Update of bug #37648 (project make): Item Group: Bug => Enhancement Triage Status: Need Info => Major Effort ___ Follow-up Comment #2: No further info is ava

[bug #15968] make fails trying to stat a .PHONY target: p\:foo

Update of bug #15968 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => 4.0 Summary: make

[bug #20542] Regression: windows gnumake + MKS shell + Special Shell Chars

Update of bug #20542 (project make): Item Group: Enhancement => None Open/Closed:Open => Closed ___ Follow-up Comment #3: 6 years have passed wi

make-4.0 test failures

Hi, A bit of an oddity this one. Building and invoking 'make check' on an x86_64 Linux box, I see this in the test output: functions/eval .. ok (9 passed) functions/file .. *** Test died (functions/file): Opened

[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 #16788] 'ORDINARY_MTIME_MAX' macro causes integral constant overflow

Follow-up Comment #2, bug #16788 (project make): Paul (Eggert) provided these macros; they are intended to work properly in various endianness, sizeof(int), sizeof(uintmax_t), etc. environments. There's something a little tricky about them related to overflow handling, in order to cause compile-t

[bug #16788] 'ORDINARY_MTIME_MAX' macro causes integral constant overflow

Follow-up Comment #1, bug #16788 (project make): Paul, The OP suggests to replace this: #define ORDINARY_MTIME_MAX ((FILE_TIMESTAMP_S (NEW_MTIME) \ << FILE_TIMESTAMP_LO_BITS) \ + ORDINARY_MTIME_MIN + FILE_TIMESTAMPS_PER_S - 1) with this:

[bug #31150] The make doesn't work on Windows x64 platforms

Update of bug #31150 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM _

[bug #40344] Can't handle Windows path names longer than 259 characters

Follow-up Comment #5, bug #40344 (project make): For the record, the place where the long file name causes trouble is in name_mtime, where Make calls stat to get the file's time stamp. It looks like Windows prepends the current directory to the file name, without paying attention to the fact that

[bug #40241] CreateProcess failure with unixy paths

Update of bug #40241 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #18, bug #40241 (project make): >From several tests, it does seem to work, despite it not following BATCH_MODE_ONLY_SHELL, which is probably due to sh.exe not screwing up with quotes with unixy paths. ___ Reply to this ite

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #17, bug #40241 (project make): MSYS Make 3.82.90 from the URL below does work well with -jN: https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/ I use that build all the time. Yes, using single quotes are also a possibility. Eventually, I need to k

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #16, bug #40241 (project make): Using single quotes seems to be another workaround. ___ Reply to this item at: ___ Message sent via/by

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #15, bug #40241 (project make): 3.8x deadlocks with -jN. As for paths, it's a complex issue. We can't reliably use msys paths everywhere (and for many reasons, we don't want to use more msys paths) ___ Reply to this item

[bug #40344] Can't handle Windows path names longer than 259 characters

Follow-up Comment #4, bug #40344 (project make): Make does not necessarily prepend the current directory, but the library functions it calls might do that internally, as part of file-name normalization. (So it's not the current directory that counts, but CURRENT_DIR/../../../../../../ in your cas

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #14, bug #40241 (project make): Indeed, that's what I see as well. Can you use the MSYS file name notation instead, as in "/c/full/path/to/python.exe"? My testing indicates that the problem disappears when this format of file names is used. Btw, these are exactly the problems

[bug #40344] Can't handle Windows path names longer than 259 characters

Follow-up Comment #3, bug #40344 (project make): It looks like it would be the case, as success: ../../../../../../this-is-a-long-path-component-0/this-is-a-long-filename.txt fails too, with the current path being the original long path. I don't think there's any SUBST or CD way out of this.

[bug #40344] Can't handle Windows path names longer than 259 characters

Follow-up Comment #2, bug #40344 (project make): Note that "../../../../../../this-is-a-long-path-component-0/this-is-a-long-path-component-1/this-is-a-long-path-component-2/this-is-a-long-path-component-3/this-is-a-long-path-component-4/this-is-a-long-path-component-5/this-is-a-long-filename.txt"

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #13, bug #40241 (project make): Err, I was not looking at the right thing. It *is* bash not handling quotes properly: CreateProcess(C:mozilla-buildmsysbinsh.exe,C:/mozilla-build/msys/bin/sh.exe -c "c:/full/path/to/python.exe foo.py "a" b d",...)

[bug #40344] Can't handle Windows path names longer than 259 characters

Update of bug #40344 (project make): Severity: 3 - Normal => 1 - Wish Item Group: Bug => Enhancement Triage Status:None => Major Effort Summary: Can'

[bug #40241] CreateProcess failure with unixy paths

Follow-up Comment #12, bug #40241 (project make): Ah no, I'm hitting it again without BATCH_MODE_ONLY_SHELL. Here is a small testcase: $ cat > foo.py < Makefile ___ Message sent via/by Savannah http://savannah