Smoke [blead] v5.21.4-91-g8fb0127 FAIL(M) MSWin32 Win2000 SP4 (x86/1 cpu) {blead}

[George Greer]

Automated smoke report for 5.21.5 patch 8fb0127d49f1fbb7e8332bf50c25ab4c34631cfa v5.21.4-91-g8fb0127
perl-win2k: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz(~2657 MHz) (x86/1 cpu)
on MSWin32 - Win2000 SP4
using cl version 14.00.50727.762
smoketime 14 minutes 30 seconds (average 3 minutes 37.500 seconds)

Summary: FAIL(M)

O = OK F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during: - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep

v5.21.4-91-g8fb0127 Configuration (common) none
----------- ---------------------------------------------------------
M M
M M -Duseithreads
| +--------- -DDEBUGGING
+----------- no debugging


Locally applied patches:
SMOKE8fb0127d49f1fbb7e8332bf50c25ab4c34631cfa

Compiler messages(MSWin32):
..\pp_pack.c(2170) : warning C4244: 'initializing' : conversion from 'I32' to 'const char', possible loss of data
..\sv.c(2071) : warning C4244: 'initializing' : conversion from 'U32' to 'char', possible loss of data
..\sv.c(7449) : warning C4244: '=' : conversion from 'STRLEN' to 'float', possible loss of data
..\sv.c(7450) : warning C4244: '=' : conversion from 'const STRLEN' to 'float', possible loss of data
..\sv.c(7453) : warning C4244: '=' : conversion from 'const STRLEN' to 'float', possible loss of data
..\sv.c(7454) : warning C4244: '=' : conversion from 'STRLEN' to 'float', possible loss of data

[Steve Hay]

Post by George Greer
Automated smoke report for 5.21.5 patch 8fb0127d49f1fbb7e8332bf50c25ab4c34631cfa v5.21.4-91-g8fb0127
on MSWin32 - Win2000 SP4
using cl version 14.00.50727.762
smoketime 14 minutes 30 seconds (average 3 minutes 37.500 seconds)
Summary: FAIL(M)

I also have a build failure on blead. It worked yesterday when I
tested my Errno changes, but I didn't re-test after rebasing on the
latest changes fetched from blead before I pushed.

Here's the failure I see now, building 5884c88b2d4d412c81919fffcc0c487b49521793:

Generating a nmake-style Makefile
Writing Makefile for B
Can't locate IO/File.pm in @INC (you may need to install the IO::File module) (@
INC contains: C:\Dev\Git\perl\lib C:\Dev\Git\perl\cpan\AutoLoader\lib C:\Dev\Git
\perl\dist\Carp\lib C:\Dev\Git\perl\dist\PathTools C:\Dev\Git\perl\dist\PathTool
s\lib C:\Dev\Git\perl\cpan\ExtUtils-Command\lib C:\Dev\Git\perl\cpan\ExtUtils-In
stall\lib C:\Dev\Git\perl\cpan\ExtUtils-MakeMaker\lib C:\Dev\Git\perl\cpan\ExtUt
ils-Manifest\lib C:\Dev\Git\perl\cpan\File-Path\lib C:\Dev\Git\perl\ext\re C:\De
v\Git\perl\dist\Term-ReadLine\lib C:\Dev\Git\perl\dist\Exporter\lib C:\Dev\Git\p
erl\ext\File-Find\lib C:\Dev\Git\perl\cpan\Text-Tabs\lib C:\Dev\Git\perl\dist\co
nstant\lib C:\Dev\Git\perl\cpan\Text-ParseWords\lib .) at C:\Dev\Git\perl\lib/Fi
leHandle.pm line 9.
Compilation failed in require at C:\Dev\Git\perl\lib/ExtUtils/Constant.pm line 5
08.
512 from ext/B's Makefile.PL at ..\make_ext.pl line 510.
Running Mkbootstrap for B ()
C:\Dev\Git\perl\miniperl.exe "-I..\..\lib" "-I..\..\lib" -MExtUtils::Com
mand -e chmod -- 644 B.bs
..\..\miniperl.exe "-I..\..\lib" "-I..\..\lib" ..\..\lib\ExtUtils\xsubpp
-typemap ..\..\lib\ExtUtils\typemap -typemap typemap B.xs > B.xsc && C:\Dev\G
it\perl\miniperl.exe "-I..\..\lib" "-I..\..\lib" -MExtUtils::Command -e mv -- B.
xsc B.c
Cannot open 'const-xs.inc': No such file or directory in B.xs, line 744
NMAKE : fatal error U1077: '..\..\miniperl.exe' : return code '0x1'
Stop.
Unsuccessful make(ext/B): code=512 at ..\make_ext.pl line 564.
NMAKE : fatal error U1077: '..\miniperl.exe' : return code '0x2'
Stop.

[Steve Hay]

Post by Steve Hay

Post by George Greer
Automated smoke report for 5.21.5 patch 8fb0127d49f1fbb7e8332bf50c25ab4c34631cfa v5.21.4-91-g8fb0127
on MSWin32 - Win2000 SP4
using cl version 14.00.50727.762
smoketime 14 minutes 30 seconds (average 3 minutes 37.500 seconds)
Summary: FAIL(M)

I also have a build failure on blead. It worked yesterday when I
tested my Errno changes, but I didn't re-test after rebasing on the
latest changes fetched from blead before I pushed.
Generating a nmake-style Makefile
Writing Makefile for B

Now bisected to 5564cd7fcb7851d713d898c22f57e6562a43a53c.

The previous commit (a13f4dff39a8e5b2dfd82fe8fb21125753c7022b) bombs
out the build on sv.c:

cl -c -I.. -nologo -GF -W3 -I..\lib\CORE -I.\include -I. -I.. -DWIN32 -D
_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DPE
RLDLL -DPERL_CORE -O1 -MD -Zi -DNDEBUG -GL -DPERL_TEXTMODE_SCRIPTS -DPERL_IMP
LICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -Fo..\sv.obj ..\sv.c
sv.c
..\sv.c(2071) : warning C4244: 'initializing' : conversion from 'U32' to 'char',
possible loss of data
..\sv.c(2085) : error C2065: 'my_perl' : undeclared identifier
..\sv.c(2085) : warning C4047: 'function' : 'PerlInterpreter *' differs in level
s of indirection from 'int'
..\sv.c(2085) : warning C4024: 'Perl_my_atof' : different types for formal and a
ctual parameter 1
..\sv.c(7446) : warning C4244: '=' : conversion from 'STRLEN' to 'float', possib
le loss of data
..\sv.c(7447) : warning C4244: '=' : conversion from 'const STRLEN' to 'float',
possible loss of data
..\sv.c(7450) : warning C4244: '=' : conversion from 'const STRLEN' to 'float',
possible loss of data
..\sv.c(7451) : warning C4244: '=' : conversion from 'STRLEN' to 'float', possib
le loss of data
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0
\VC\BIN\cl.EXE"' : return code '0x2'
Stop.

The commit before that (5bf8b78e07edcdb636cf0f1a8c1e9e97f2ce2f53) builds ok.

[Jarkko Hietaniemi]

Post by Steve Hay

Post by Steve Hay
I also have a build failure on blead. It worked yesterday when I

Post by Steve Hay
tested my Errno changes, but I didn't re-test after rebasing on the
latest changes fetched from blead before I pushed.
Generating a nmake-style Makefile
Writing Makefile for B

Now bisected to 5564cd7fcb7851d713d898c22f57e6562a43a53c.
The previous commit (a13f4dff39a8e5b2dfd82fe8fb21125753c7022b) bombs

So... is this still broken? Threaded builds are still happy, which is
what 5564cd7fcb7851d713d898c22f57e6562a43a53c was fixing.

[Steve Hay]

-----Original Message-----
From: ***@iki.fi [mailto:***@gmail.com] On Behalf Of Jarkko Hietaniemi
Sent: 25 September 2014 14:55
To: Steve Hay; George Greer
Cc: smokers-***@perl.org; perl5-***@perl.org
Subject: Re: Smoke [blead] v5.21.4-91-g8fb0127 FAIL(M) MSWin32 Win2000 SP4 (x86/1 cpu) {blead}

Post by Steve Hay

Post by Steve Hay
I also have a build failure on blead. It worked yesterday when I

Post by Steve Hay
tested my Errno changes, but I didn't re-test after rebasing on the
latest changes fetched from blead before I pushed.
Generating a nmake-style Makefile
Writing Makefile for B

Now bisected to 5564cd7fcb7851d713d898c22f57e6562a43a53c.
The previous commit (a13f4dff39a8e5b2dfd82fe8fb21125753c7022b) bombs

So... is this still broken? Threaded builds are still happy, which is what 5564cd7fcb7851d713d898c22f57e6562a43a53c was fixing.


Yes, the default build on Win32/VC10 is curre

[Jarkko Hietaniemi]

Yes, the default build on Win32/VC10 is currently broken. (And it is a threaded build by default!)

Win32 threaded != UNIX threaded, then... I don't off-hand see how
static function in sv.c can break a build in an ext/ directory :-(

[Karl Williamson]

Post by Jarkko Hietaniemi

Yes, the default build on Win32/VC10 is currently broken. (And it is a
threaded build by default!)

Win32 threaded != UNIX threaded, then... I don't off-hand see how
static function in sv.c can break a build in an ext/ directory :-(

It's failing for me on Linux as well. I dare not rebase my work spaces
because of it.

config_args='-des -Dprefix=/home/khw/fastbleadperl -Dusedevel
-Accflags='-DPERL _BOOL_AS_CHAR' -Dman1dir=none -Dman3dir=none
-Dusemorebits -Dusethreads'


(but it's a 64 bit machine; the usemorebits was something I did back
when I had a 32 bit one.)

[Jarkko Hietaniemi]

Post by Karl Williamson
It's failing for me on Linux as well. I dare not rebase my work spaces
because of it.
config_args='-des -Dprefix=/home/khw/fastbleadperl -Dusedevel
-Accflags='-DPERL _BOOL_AS_CHAR' -Dman1dir=none -Dman3dir=none
-Dusemorebits -Dusethreads'

Thanks, I'll try to repro in dromedary.

Post by Karl Williamson
(but it's a 64 bit machine; the usemorebits was something I did back
when I had a 32 bit one.)

[Jarkko Hietaniemi]

Post by Jarkko Hietaniemi

Post by Karl Williamson
It's failing for me on Linux as well. I dare not rebase my work spaces
because of it.
config_args='-des -Dprefix=/home/khw/fastbleadperl -Dusedevel
-Accflags='-DPERL _BOOL_AS_CHAR' -Dman1dir=none -Dman3dir=none
-Dusemorebits -Dusethreads'

Thanks, I'll try to repro in dromedary.

I'm about to push two tweaks related to this mess that that are
however unlikely to unwedge the brokenness; just a heads-up to dampen
the expectations.

Post by Jarkko Hietaniemi

Post by Karl Williamson
(but it's a 64 bit machine; the usemorebits was something I did back
when I had a 32 bit one.)

[Karl Williamson]

Post by Karl Williamson

Post by Jarkko Hietaniemi

Yes, the default build on Win32/VC10 is currently broken. (And it is a
threaded build by default!)

Win32 threaded != UNIX threaded, then... I don't off-hand see how
static function in sv.c can break a build in an ext/ directory :-(

It's failing for me on Linux as well. I dare not rebase my work spaces
because of it.
config_args='-des -Dprefix=/home/khw/fastbleadperl -Dusedevel
-Accflags='-DPERL _BOOL_AS_CHAR' -Dman1dir=none -Dman3dir=none
-Dusemorebits -Dusethreads'
(but it's a 64 bit machine; the usemorebits was something I did back
when I had a 32 bit one.)

I forgot to mention that I have noticed that the files like
'const-xs.inc' do not have proper makefile dependencies created for
them. That is they don't get rebuilt when the files they depend on change.
This predates this particular problem, but may be related

[Father Chrysostomos]

Post by Jarkko Hietaniemi

Post by Steve Hay
Now bisected to 5564cd7fcb7851d713d898c22f57e6562a43a53c.

So... is this still broken? Threaded builds are still happy, which is
what 5564cd7fcb7851d713d898c22f57e6562a43a53c was fixing.

The bad code was added in a13f4dff39, but probably didn't compile
under threads till 5564cd7f.

I fixed it in 07925c5. (I don't know whether this fixes the failures
Karl Williamson was seeing.)

BTW, you can catch this sort of thing by building with
-Accflags=-DPERL_BOOL_AS_CHAR.

[Jarkko Hietaniemi]

Post by Father Chrysostomos
BTW, you can catch this sort of thing by building with
-Accflags=-DPERL_BOOL_AS_CHAR.

Wow, thank! It seems that none of my usual systems have that
setting. Didn't get around trying this yet, was busy on errands.

[Jarkko Hietaniemi]

Post by Father Chrysostomos
BTW, you can catch this sort of thing by building with
-Accflags=-DPERL_BOOL_AS_CHAR.

grep -n 'bool .* = .*OK' *.c|grep -v cBOOL

finds some potential trouble places.

[Father Chrysostomos]

Post by Jarkko Hietaniemi
grep -n 'bool .* = .*OK' *.c|grep -v cBOOL
finds some potential trouble places.

SvUOK is defined in terms of ==. Anything with && on the rhs is fine.
So those are false positives.

[Steve Hay]

Post by Father Chrysostomos

Post by Jarkko Hietaniemi

Post by Steve Hay
Now bisected to 5564cd7fcb7851d713d898c22f57e6562a43a53c.

So... is this still broken? Threaded builds are still happy, which is
what 5564cd7fcb7851d713d898c22f57e6562a43a53c was fixing.

The bad code was added in a13f4dff39, but probably didn't compile
under threads till 5564cd7f.
I fixed it in 07925c5. (I don't know whether this fixes the failures
Karl Williamson was seeing.)

Thanks for the fix :-)