For the actual use case, see the discussion on the MinGW mailing list about that. The important part starts here:
https://sourceforge.net/mailarchive/message.php?msg_id=30846737 To make the long story short: . The problem is a complete failure of Make to run, where it bails out before even trying to look for a Makefile, with the error message cited in the subject. (The error message is quite cryptic, and it took a while to understand what is causing it.) . This happens when Make looks for a suitable shell, see the function find_and_set_default_shell, which is Windows specific. As part of that function, Make looks along PATH for the executable file named sh.exe. For each directory on PATH, Make calls file_exists_p to find out whether sh.exe exists in that directory. That call then eventually winds up in dir_contents_file_exists_p, where we have this snippet: ENULLLOOP (d, readdir (dir->dirstream)); if (d == 0) { if (errno) fatal (NILF, "INTERNAL: readdir: %s\n", strerror (errno)); break; } . It turns out that, for whatever reasons, if there's a file with non-ASCII characters in some directory on PATH, MinGW's 'readdir' sometimes returns a non-zero errno value. (I suspect that the problem is with non-ASCII characters that are not representable in the current console codepage encoding, but that's a guess, since I cannot reproduce this on my system.) . When that problem happens, Make exits with a fatal error, as you see from the code snippet above. The user is left wondering what the heck happened, since no useful diagnostics is shown. Question: Why do we force a fatal error when 'readdir' fails in that way? Would it be better to display a warning, perhaps even under some debug command-line option, and otherwise simply treat that as the end of the directory stream? If we do want to force a failure in this case, I guess I will need to look for a Windows-specific solution, since other platforms don't use dir_contents_file_exists_p to look for files that are not explicitly mentioned in the Makefile. Most probably, I will refrain from calling file_exists_p entirely in find_and_set_default_shell, and instead test for the existence of the shell executable file by trying to access it directly. Comments? _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
