Front page | perl.perl5.porters |
Postings from October 2015
> 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