On Fri, Jun 16, 2017 at 11:49 AM, Orgad Shaneh <org...@gmail.com> wrote:
> On Fri, Jun 16, 2017 at 9:23 AM, Eli Zaretskii <e...@gnu.org> wrote: > >> > From: Orgad Shaneh <org...@gmail.com> >> > Date: Fri, 16 Jun 2017 00:46:34 +0300 >> > >> > Ok, I found out that the bug is not (entirely) in make. What causes >> this problem is the following patch applied >> > by MSYS2 packages of mingw make: >> > >> > diff -Naur make-4.2.1/main.c make-4.2.1.new/main.c >> > --- make-4.2.1/main.c 2016-05-31 09:17:26.000000000 +0200 >> > +++ make-4.2.1.new/main.c 2017-02-20 22:55:09.051617838 +0100 >> > @@ -1126,8 +1126,11 @@ >> > >> > #endif >> > >> > +/* setlocale interferes with line buffering if using parallel make on >> MinGW */ >> > +#ifndef __MINGW32__ >> > /* Set up gettext/internationalization support. */ >> > setlocale (LC_ALL, ""); >> > +#endif >> > /* The cast to void shuts up compiler warnings on systems that >> > disable NLS. */ >> > (void)bindtextdomain (PACKAGE, LOCALEDIR); >> >> I'd certainly like to know why "setlocale interferes with line >> buffering if using parallel make on MinGW". Could you perhaps ask the >> MSYS2 maintainers to report their findings here or on make-w32? >> >> TIA >> > > I'm not sure, but you can see in my bug report that the output is > interleaved without this patch. > > On Fri, Jun 16, 2017 at 9:29 AM, Eli Zaretskii <e...@gnu.org> wrote: > >> > From: Orgad Shaneh <org...@gmail.com> >> > Date: Fri, 16 Jun 2017 01:16:09 +0300 >> > >> > ... or not. I still get it even without this patch, when running from >> IDE. Reverting the patch only fixes the issue >> > when running in command line. >> > >> > I did file a bug[1], but this is not the real reason. Probably timing >> issue. >> >> Most probably. It also could be indirectly caused by your recipes. >> > > Unlikely. I reduced it to the most minimal recipe (build a single c++ > file), and it still happens > > > Another thing I've noticed is that make (on Windows/MinGW) leaves behind >> suspended processes when it is >> > aborted. Maybe one of these processes holds the file and prevents it >> from being deleted? >> >> Could be, you should be able to use Process Explorer to see who holds >> a handle on the files that fail to be deleted. >> > > The handle is released immediately after make is done. > > >> In general, killing subprocesses is problematic on Windows, because >> only child processes can be killed, the grandchildren cannot. >> Therefore, rearranging your build commands might make the issue go >> away. >> > > Then this can explain the problem. g++.exe invokes a child process > cc1plus.exe. Maybe g++ is killed, but cc1plus still has the file open. Then > both g++ and make try to unlink the file, but they both fail. I attach a > Process Monitor log for this scenario. > > I think g++ is the most common use-case for make, so this must be handled > properly. > > >> >> > If you can suggest ways to debug and fix this problem, I'll be thankful. >> >> Well, I'd start by posting a minimal Makefile and auxiliary files that >> allow to reproduce the issue. >> > > I'll try to create one later. > > >> >> Another approach would be to try the MinGW build here: >> >> https://sourceforge.net/projects/ezwinports/files/?source=navbar >> >> where you can also find Make built with Guile support, something I >> don't think MSYS2 guys offer. >> > > It's the same. > > > - Orgad > Ok, I was able to create a minimal example. It happens only with g++ -pipe. fib.cpp (takes very long to compile): #include <iostream> template <int TreePos, int N> struct FibSlow_t { enum { value = FibSlow_t<TreePos, N - 1>::value + FibSlow_t<TreePos + (1 << N), N - 2>::value, }; }; template <int TreePos> struct FibSlow_t<TreePos, 1> { enum { value = 1 }; }; // Explicitly specialized for N==1 template <int TreePos> struct FibSlow_t<TreePos, 0> { enum { value = 0 }; }; using namespace std; int main() { cout<<FibSlow_t<0, 70>::value<<endl; } ------- Makefile: fib.o: fib.cpp g++ -pipe -c -o fib.o fib.cpp Run make fib.o, then Ctrl-C. - Orgad
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
