> Date: Sun, 18 Oct 2015 13:57:36 +0100 > Subject: Re: GCC builds failing many tests on Windows > From: perl5-porters@perl.org > To: bulk88@hotmail.com > CC: perl5-porters@perl.org > > It isn't a parallel build; it's just a straight "dmake". But you're > right that ext/POSIX/const-c.inc and ext/POSIX/const-xs.inc are both 0 > bytes, which is rather worrying, especially since this happens every > time for me... For me it happens only when doing a "dmake all" or "dmake test" parallel (-P3) build. If I do "dmake -P3 Extensions" POSIX builds correctly every time, so I think the race is between Extensions_nonxs and Extensions targets (both are make_ext.pl runs) in parallel mode. Whether I use Visual C or GCC with dmake makefile doesnt seem to make a difference. A git clean and another "dmake -P3 all" and POSIX builds usually builds normal. If I drop the -P3, git clean, goto serial dmake build it always goes away. I've never had the bug hit more than 2 times in a row in parallel mode with git cleans between. When I tried to step POSIX's Makefile.PL a month ago, those 2 files always get written out to disk correctly. > I'm using http://search.cpan.org/~shay/dmake-4.12.2.2/ I guess you're > probably using something newer? If so, where is the best place to get > 4.13 or whatever it is now? And can you reproduce the problem using my > old 4.12.2.2? I dont think it has anything to do with dmake.exe, but some of the changes I did to makefile.mk to enable parallel building. There might be a "eval { require Foo;}" somewhere inside WriteConstants sub or an flock or a timestamp compare if($mtime1 > $mtime2) {print "do good behavior";} else {print "do bad";} and $mtime1 == $mtime2 or something. Or an eval block followed by an exit 0; in an exception handler that is swallowing an error. It can be fixed, I just can't reproduce it enough to debug it on my machines. > We really need the non-parallel build, at least, to work reliably with > the current CPAN release. If it needs 4.13 for some reason then we > need to get that onto CPAN. I thought Ed J was going to do that a long > time, but it still hasn't happened yet. I don't really see why it > should be necessary for a non-parallel build, though. My 4.13 branch is stalled since it can't compile on Mingw GCC due to it needing to call an exported VC mangled C++ function from msvcrt.dll and it is not easy to call VC C++ funcs from GCC when the 2 CCs intentionally use different C++ name manglers (my first solution ended in a bug ticket that I know will never be fixed https://sourceware.org/bugzilla/show_bug.cgi?id=18640 ). So until dmake 4.13 compiles on Mingw/autoconf, Ed J said he wont release it.Thread Previous | Thread Next