develooper Front page | perl.perl5.porters | Postings from October 2015

RE: GCC builds failing many tests on Windows

Thread Previous | Thread Next
bulk 88
October 18, 2015 19:37
RE: GCC builds failing many tests on Windows
Message ID:

> Date: Sun, 18 Oct 2015 13:57:36 +0100
> Subject: Re: GCC builds failing many tests on Windows
> From:
> To:
> CC:
> It isn't a parallel build; it's just a straight "dmake". But you're
> right that ext/POSIX/ and ext/POSIX/ 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 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 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

I dont think it has anything to do with dmake.exe, but some of the changes I did to 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 ). So until dmake 4.13 compiles on Mingw/autoconf, Ed J said he wont release it.
Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About