Skip Menu |
Report information
Id: 132860
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: randir <sergey.aleynikov [at] gmail.com>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: core
Perl Version: 5.27.9
Fixed In: (no value)



Subject: RFC on windows build status
From: Sergey Aleynikov <sergey.aleynikov [...] gmail.com>
Date: Mon, 12 Feb 2018 23:46:58 +0300
To: perlbug [...] perl.org
Download (untitled) / with headers
text/plain 4.1k
This is a bug report for perl from sergey.aleynikov@gmail.com, generated with the help of perlbug 1.41 running under perl 5.27.9. ----------------------------------------------------------------- [Please describe your issue here] I've recently done a Perl build on a Windows machine using VS 2017 and found it's status a bit alarming: - perlwin32.html (aka README.win32) states "There should be no test failures.", but at least three tests failed for 64-bit build (console window is by default too small, so I haven't recorded them) and I ended up with cpan/IPC-Cmd/t/01_IPC-Cmd.t stuck (for at least 10 minutes, until I've aborted it). Are those failures known? If not, should I report them, or there're not enough volunteers to fix them, so it's time to change the docs? - during both 32-bit and 64-bit builds, I've seen a lot of warnings about variables size mismatch conversions (in both ways). Most of them seem to have the same underlying source, but they're really numerous. Or is windows build currently supported only as a MinGW Strawberry build by it's community? [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=low --- Site configuration information for perl 5.27.9: Configured by root at Sun Feb 11 01:07:53 MSK 2018. Summary of my perl5 (revision 5 version 27 subversion 9) configuration: Commit id: c0e3b4b51cabf15ed8fc5f564dfeea31c25f5239 Platform: osname=linux osvers=4.9.0-5-amd64 archname=x86_64-linux uname='linux dorothy 4.9.0-5-amd64 #1 smp debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 gnulinux ' config_args='-de -Dusedevel' hint=recommended useposix=true d_sigaction=define useithreads=undef usemultiplicity=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='cc' ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2' optimize='-O2' cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include' ccversion='' gccversion='6.3.0 20170516' gccosandvers='' intsize=4 longsize=8 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=3 ivtype='long' ivsize=8 nvtype='double' nvsize=8 Off_t='off_t' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='cc' ldflags =' -fstack-protector-strong -L/usr/local/lib' libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc libc=libc-2.24.so so=so useshrplib=false libperl=libperl.a gnulibc_version='2.24' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=so d_dlsymun=undef ccdlflags='-Wl,-E' cccdlflags='-fPIC' lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong' --- @INC for perl 5.27.9: lib /usr/local/lib/perl5/site_perl/5.27.9/x86_64-linux /usr/local/lib/perl5/site_perl/5.27.9 /usr/local/lib/perl5/5.27.9/x86_64-linux /usr/local/lib/perl5/5.27.9 --- Environment for perl 5.27.9: HOME=/home/afl LANG=en_US.UTF-8 LANGUAGE=en_US:en LC_CTYPE=en_US.UTF-8 LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/afl/perlbrew/bin:/home/afl/perlbrew/perls/perl-5.20.2/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games PERLBREW_BASHRC_VERSION=0.78 PERLBREW_HOME=/home/afl/.perlbrew PERLBREW_MANPATH=/home/afl/perlbrew/perls/perl-5.20.2/man PERLBREW_PATH=/home/afl/perlbrew/bin:/home/afl/perlbrew/perls/perl-5.20.2/bin PERLBREW_PERL=perl-5.20.2 PERLBREW_ROOT=/home/afl/perlbrew PERLBREW_VERSION=0.78 PERL_BADLANG (unset) SHELL=/usr/bin/zsh
To: Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #132860] RFC on windows build status
From: Steve Hay <steve.m.hay [...] googlemail.com>
Date: Mon, 12 Feb 2018 21:49:02 +0000
CC: bugs-bitbucket [...] rt.perl.org
Download (untitled) / with headers
text/plain 2.3k
On 12 February 2018 at 20:47, Sergey Aleynikov <perlbug-followup@perl.org> wrote: Show quoted text
> # New Ticket Created by Sergey Aleynikov > # Please include the string: [perl #132860] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=132860 > > > > This is a bug report for perl from sergey.aleynikov@gmail.com, > generated with the help of perlbug 1.41 running under perl 5.27.9. > > > ----------------------------------------------------------------- > [Please describe your issue here] > > I've recently done a Perl build on a Windows machine using VS 2017 and > found it's status a bit alarming: > > - perlwin32.html (aka README.win32) states "There should be no test > failures.", but at least three tests failed for 64-bit build (console > window is by default too small, so I haven't recorded them) and I > ended up with cpan/IPC-Cmd/t/01_IPC-Cmd.t stuck (for at least 10 > minutes, until I've aborted it). Are those failures known? If not, > should I report them, or there're not enough volunteers to fix them, > so it's time to change the docs?
I just did a build with VS2015 and found three or four tests hung. I killed the hung perl.exe processes to let it continue more quickly. Some have a "watchdog" timeout on them so would continue eventually. This used to be quite a problem but I thought things had got better more recently. I will try some more tests with different compilers/systems. No tests failed other than the ones I killed. There shouldn't be any test failures, other than what is documented in README.win32. If there are any then they need fixing, skipping or documenting as appropriate. Show quoted text
> > - during both 32-bit and 64-bit builds, I've seen a lot of warnings > about variables size mismatch conversions (in both ways). Most of them > seem to have the same underlying source, but they're really numerous.
Lots of warnings are, unfortunately, normal with some versions. I think older ones (e.g. VC6) and 64-bit builds tend to be worst. I've often tried to iron them out, but they always creep back in over time. I thought recent versions (e.g. VS2015) in 32-bit builds only had a small number of warnings, but I've not looked closely for a while. Show quoted text
> > Or is windows build currently supported only as a MinGW Strawberry > build by it's community?
Visual C++ builds are definitely very much still supported.
CC: bugs-bitbucket [...] rt.perl.org
From: Steve Hay <steve.m.hay [...] googlemail.com>
Date: Mon, 12 Feb 2018 22:06:24 +0000
Subject: Re: [perl #132860] RFC on windows build status
To: Perl5 Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 2.7k
On 12 February 2018 at 21:49, Steve Hay <steve.m.hay@googlemail.com> wrote: Show quoted text
>> - during both 32-bit and 64-bit builds, I've seen a lot of warnings >> about variables size mismatch conversions (in both ways). Most of them >> seem to have the same underlying source, but they're really numerous.
> > Lots of warnings are, unfortunately, normal with some versions. I > think older ones (e.g. VC6) and 64-bit builds tend to be worst. I've > often tried to iron them out, but they always creep back in over time. > I thought recent versions (e.g. VS2015) in 32-bit builds only had a > small number of warnings, but I've not looked closely for a while. >
From a 32-bit VS2015 build I have only these warnings from core code: ..\mathoms.c(694): warning C4028: formal parameter 2 different from declaration ..\pad.c(2755): warning C4267: '=': conversion from 'size_t' to 'U8', possible loss of data ..\pp_sys.c(2234): warning C4244: 'initializing': conversion from '__int64' to 'NV', possible loss of data ..\pp_sys.c(4719): warning C4244: 'initializing': conversion from 'time_t' to 'IV', possible loss of data ..\pp_sys.c(4919): warning C4244: 'initializing': conversion from 'time_t' to 'IV', possible loss of data ..\regcomp.c(3393): warning C4267: '+=': conversion from 'size_t' to 'U8', possible loss of data ..\regcomp.c(12538): warning C4267: '=': conversion from 'size_t' to 'U8', possible loss of data ..\regcomp.c(13989): warning C4267: '=': conversion from 'size_t' to 'U8', possible loss of data ..\regcomp.c(19150): warning C4244: 'initializing': conversion from 'U32' to 'const U8', possible loss of data ..\regexec.c(2253): warning C4244: 'function': conversion from 'U32' to 'const U8', possible loss of data ..\sv.c(12562): warning C4244: '=': conversion from 'PERL_INTMAX_T' to 'IV', possible loss of data ..\sv.c(12617): warning C4244: '=': conversion from 'PERL_UINTMAX_T' to 'UV', possible loss of data vdir.h(649): warning C4244: 'argument': conversion from 'const WCHAR' to 'char', possible loss of data win32.c(4495): warning C4996: 'GetVersionExA': was declared deprecated and these from modules: MD5.xs(763): warning C4244: '=': conversion from 'U32' to 'char', possible loss of data MD5.xs(764): warning C4244: '=': conversion from 'U32' to 'char', possible loss of data MD5.xs(765): warning C4244: '=': conversion from 'U32' to 'char', possible loss of data MD5.xs(766): warning C4244: '=': conversion from 'U32' to 'char', possible loss of data sdbm.c(38): warning C4273: 'malloc': inconsistent dll linkage sdbm.c(39): warning C4273: 'free': inconsistent dll linkage Socket.xs(959): warning C4244: '=': conversion from 'unsigned long' to 'unsigned short', possible loss of data Win32.xs(1771): warning C4996: 'GetVersionExA': was declared deprecated
RT-Send-CC: perl5-porters [...] perl.org

Message body is not shown because it is too large.

Date: Mon, 19 Feb 2018 09:11:16 +0000
Subject: Re: [perl #132860] RFC on windows build status
To: perlbug-followup [...] perl.org
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
On 19 February 2018 at 00:06, Sergey Aleynikov via RT <perlbug-followup@perl.org> wrote: Show quoted text
> Here's what I've got with a x64 build using MSVC 2017. > > Build warnings part: >
[...] Show quoted text
> Build warnings in modules: >
[...] That's about the same as I get with VS2015 or VS2017 in x64 builds. x86 builds fare much better, though VC6 has lots of warnings. Show quoted text
> > Test failures part: > > ../cpan/IPC-Cmd/t/01_IPC-Cmd.t - hangs and has to be killed
I occasionally see certain tests (01_IPC-Cmd.t is one of them) hanging and needing to be killed, but it only seems to happen on my Windows 7 machine. On Windows 8 I've yet to see it happen. I don't know if that's due to the OS, or other differences, e.g. they have different anti-virus software on them. Show quoted text
> > Full result is: > > Test Summary Report > ------------------- > porting/checkcfgvar.t (Wstat: 0 Tests: 24 Failed: 1) > Failed test: 23 > porting/customized.t (Wstat: 0 Tests: 28 Failed: 28) > Failed tests: 1-28 > porting/pod_rules.t (Wstat: 0 Tests: 6 Failed: 5) > Failed tests: 2-6 > Parse errors: Bad plan. You planned 8 tests but ran 6. > porting/regen.t (Wstat: 65280 Tests: 11 Failed: 1) > Failed test: 11 > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 43 tests but ran 11. > ../cpan/CPAN-Meta-YAML/t/30_yaml_spec_tml.t (Wstat: 512 Tests: 0 Failed: 0) > Non-zero exit status: 2 > Parse errors: No plan found in TAP output > ../cpan/CPAN-Meta-YAML/t/31_local_tml.t (Wstat: 512 Tests: 0 Failed: 0) > Non-zero exit status: 2 > Parse errors: No plan found in TAP output > ../cpan/CPAN-Meta-YAML/t/32_world_tml.t (Wstat: 512 Tests: 0 Failed: 0) > Non-zero exit status: 2 > Parse errors: No plan found in TAP output > ../cpan/IPC-Cmd/t/01_IPC-Cmd.t (Wstat: 256 Tests: 20 Failed: 0) > Non-zero exit status: 1 > Parse errors: No plan found in TAP output > ../cpan/podlators/t/text/encoding.t (Wstat: 65280 Tests: 1 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 7 tests but ran 1.
This is MUCH more worrying. I don't get any test failures on either OS with either VS2015 or VS2017, whether x86 or x64, other than from tests that hung and I had to kill. Is this run from a clean git workspace? I'm trying to picture how something like porting/customized.t could possibly fail. Do you have any modified/staged/committed files? Are you using the full VS2017, or the free (Community Edition) version? I don't think I ever got round to trying the latter, though I can't imagine it would cause porting/customized.t to fail. Have you set CCTYPE=MSVC141? Please can you re-run some of those failed tests with the verbose option to get a better idea of what's going on? e.g. (from the t/ folder): .\perl harness -v porting\customized.t
From: <sisyphus1 [...] optusnet.com.au>
To: "Steve Hay" <steve.m.hay [...] googlemail.com>, <perlbug-followup [...] perl.org>
Date: Mon, 19 Feb 2018 22:05:37 +1100
Subject: Re: [perl #132860] RFC on windows build status
Download (untitled) / with headers
text/plain 1.2k
Show quoted text
-----Original Message----- From: Steve Hay via perl5-porters Sent: Monday, February 19, 2018 8:11 PM To: perlbug-followup@perl.org Subject: Re: [perl #132860] RFC on windows build status
> I occasionally see certain tests (01_IPC-Cmd.t is one of them) hanging and > needing to be killed, but it only seems to happen on my Windows 7 machine. > On Windows 8 I've yet to see it happen. I don't know if that's due to the > OS, or other differences, e.g. they have different anti-virus software on > them.
cpan/IPC-Cmd/t/01_IPC-Cmd.t always hangs for me with my x64 mingw builds on Windows 7, as too does cpan/IO-Compress/t/105oneshot-rawdeflate.t. These are the only two test files that hang for me, and there's no such hanging with x86 builds. Also, the hangs occur only when run in 'make test'. When run normally as perl scripts, there's no problem at all and both of those offending test scripts then pass. This leads me to believe that it's unlikely that anti-virus software is to blame, rather that it's maybe something that Test::Harness is doing. (My Windows 7 box doesn't have any active anti-virus software.) I've pretty much given up on being bothered by these hangs. I just kill them in Process Explorer (procexp.exe) , which allows the rest of the test suite to be run. Cheers, Rob
Subject: Re: [perl #132860] RFC on windows build status
Date: Mon, 19 Feb 2018 12:54:36 +0100
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 79.6k

Message body is not shown because it is too large.

Message body is not shown because it is too large.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
On Mon, 19 Feb 2018 01:11:35 -0800, shay wrote: Show quoted text
>From a 32-bit VS2015 build I have only these warnings from core code:
Yes, x86 build is much more clearer. I haven't compared it on a line-by-line basis, but warnings look really similar to what you've posted before. Show quoted text
> I occasionally see certain tests (01_IPC-Cmd.t is one of them) hanging > and needing to be killed, but it only seems to happen on my Windows 7 > machine. On Windows 8 I've yet to see it happen. I don't know if > that's due to the OS, or other differences, e.g. they have different > anti-virus software on them.
This is indeed Windows 7, but it's a clean machine without any antivirus software installed (MS default one is switched off too). But this contradicts documented behaviour "all tests should pass". Show quoted text
> Is this run from a clean git workspace? I'm trying to picture how > something like porting/customized.t could possibly fail. Do you have > any modified/staged/committed files?
Show quoted text
> Have you set CCTYPE=MSVC141?
This is a build done after 'git clean -dfx' was made from 'c:/perl-git' dir. I'll try to build from a fresh checkout. There're only two modified files: - Makefile for CCTYPE and/or WIN64 - config.vc for 'ar' I'll check exact value set for CCTYPE, but it's not the default one (I've picked one from README.win32 recommendations). Show quoted text
> Are you using the full VS2017, or the free (Community Edition) > version? I don't think I ever got round to trying the latter, though I > can't imagine it would cause porting/customized.t to fail.
This is a CE VS 2017. Show quoted text
> Please can you re-run some of those failed tests with the verbose > option to get a better idea of what's going on? > e.g. (from the t/ folder): .\perl harness -v porting\customized.t
Yes, I'm planning to report all individual failures/warnings for all modules involved, and will send detailed report for core tests here.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 31.4k

Message body is not shown because it is too large.

From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
CC: "Perl5 Porters (E-mail)" <perl5-porters [...] perl.org>
To: Craig Berry via RT <perlbug-followup [...] perl.org>
Date: Mon, 19 Feb 2018 14:41:17 -0600
Subject: Re: [perl #132860] RFC on windows build status
Download (untitled) / with headers
text/plain 685b
On Mon, Feb 19, 2018 at 2:21 PM, Sergey Aleynikov via RT <perlbug-followup@perl.org> wrote: Show quoted text
> On Mon, 19 Feb 2018 01:11:35 -0800, shay wrote: >
>> Is this run from a clean git workspace? I'm trying to picture how >> something like porting/customized.t could possibly fail. Do you have >> any modified/staged/committed files?
> > So, here's a run from a clean checkout with the following config applied:
What line ending policy do you have set in your git repository? I think the recommendation is to check out with CRLF endings and push with Unix-style endings (maybe someone can confirm that?). I ask because things that checksum file contents seem to be getting the wrong answer.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 480b
On Mon, 19 Feb 2018 12:41:35 -0800, craig.a.berry@gmail.com wrote: Show quoted text
> What line ending policy do you have set in your git repository? I > think the recommendation is to check out with CRLF endings and push > with Unix-style endings (maybe someone can confirm that?). I ask > because things that checksum file contents seem to be getting the > wrong answer.
All build have been done with core.autocrlf set to '' (default). I've tries another one with 'true', it changed nothing.
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
CC: Perl5 Porters <perl5-porters [...] perl.org>
Date: Tue, 20 Feb 2018 08:06:45 +0000
Subject: Re: [perl #132860] RFC on windows build status
To: perlbug-followup [...] perl.org
On 19 February 2018 at 21:39, Sergey Aleynikov via RT <perlbug-followup@perl.org> wrote: Show quoted text
> On Mon, 19 Feb 2018 12:41:35 -0800, craig.a.berry@gmail.com wrote:
>> What line ending policy do you have set in your git repository? I >> think the recommendation is to check out with CRLF endings and push >> with Unix-style endings (maybe someone can confirm that?). I ask >> because things that checksum file contents seem to be getting the >> wrong answer.
> > > All build have been done with core.autocrlf set to '' (default). I've tries another one with 'true', it changed nothing. >
I agree with Craig it's highly likely to be EOL problems - that's surely the only reason that all those porting tests could be failing. My .gitconfig file contains [core] autocrlf = false and all the files in my workspace have UNIX-style EOLs. Make a new workspace like that and try again? Btw, what is the reason that you change the 'ar' entry in config.vc? I never do that (though it would be nothing to do with the porting test failures, obviously). Is that because of a limitation in the Community Edition of Visual Studio?
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>, Steve Hay <steve.m.hay [...] googlemail.com>
Subject: Re: [perl #132860] RFC on windows build status
Date: Tue, 20 Feb 2018 11:55:56 +0100
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 828b
On 19 Feb 2018 19:54, "demerphq" <demerphq@gmail.com> wrote:
Show quoted text
On 19 Feb 2018 08:07, "Sergey Aleynikov via RT" <perlbug-followup@perl.org> wrote:
Here's what I've got with a x64 build using MSVC 2017.

Build warnings part:

c:\perl-git\zaphod32_hash.h(221): warning C4267: 'initializing': conversion from 'size_t' to 'U32', possible loss of data

Fwiw, this is unexpected to me. Zaphod32 should not by default be used on 64 bit builds. There would appear to be a failure in our detection.

I don't have the code available to check myself, but it would be nice to fix whatever is going wrong in hv_func.h so that you use stadtx64, possibly with sbox hash, instead. The warning I think is from this.


Steve while it's not the main focus of this ticket is there any chance you could poke into why it's not using Stadtx64?

Yves


Show quoted text

Date: Tue, 20 Feb 2018 13:39:53 +0000
Subject: Re: [perl #132860] RFC on windows build status
To: demerphq <demerphq [...] gmail.com>
CC: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.1k
On 20 February 2018 at 10:55, demerphq <demerphq@gmail.com> wrote: Show quoted text
> On 19 Feb 2018 19:54, "demerphq" <demerphq@gmail.com> wrote: > > On 19 Feb 2018 08:07, "Sergey Aleynikov via RT" <perlbug-followup@perl.org> > wrote: > > Here's what I've got with a x64 build using MSVC 2017. > > Build warnings part: > > c:\perl-git\zaphod32_hash.h(221): warning C4267: 'initializing': conversion > from 'size_t' to 'U32', possible loss of data > > > Fwiw, this is unexpected to me. Zaphod32 should not by default be used on 64 > bit builds. There would appear to be a failure in our detection. > > I don't have the code available to check myself, but it would be nice to fix > whatever is going wrong in hv_func.h so that you use stadtx64, possibly with > sbox hash, instead. The warning I think is from this. > > > > Steve while it's not the main focus of this ticket is there any chance you > could poke into why it's not using Stadtx64? >
hv_func.h correctly chooses STATDX, but it includes sbox32_hash.h just before the choice is made. That includes zaphod32_hash.h, hence the warning appears even though we aren't using that algorithm.
Date: Tue, 20 Feb 2018 15:42:34 +0100
Subject: Re: [perl #132860] RFC on windows build status
To: Steve Hay <steve.m.hay [...] googlemail.com>
CC: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 1.3k
On 20 Feb 2018 21:39, "Steve Hay" <steve.m.hay@googlemail.com> wrote:
Show quoted text
On 20 February 2018 at 10:55, demerphq <demerphq@gmail.com> wrote:
> On 19 Feb 2018 19:54, "demerphq" <demerphq@gmail.com> wrote:
>
> On 19 Feb 2018 08:07, "Sergey Aleynikov via RT" <perlbug-followup@perl.org>
> wrote:
>
> Here's what I've got with a x64 build using MSVC 2017.
>
> Build warnings part:
>
> c:\perl-git\zaphod32_hash.h(221): warning C4267: 'initializing': conversion
> from 'size_t' to 'U32', possible loss of data
>
>
> Fwiw, this is unexpected to me. Zaphod32 should not by default be used on 64
> bit builds. There would appear to be a failure in our detection.
>
> I don't have the code available to check myself, but it would be nice to fix
> whatever is going wrong in hv_func.h so that you use stadtx64, possibly with
> sbox hash, instead. The warning I think is from this.
>
>
>
> Steve while it's not the main focus of this ticket is there any chance you
> could poke into why it's not using Stadtx64?
>

hv_func.h correctly chooses STATDX, but it includes sbox32_hash.h just
before the choice is made. That includes zaphod32_hash.h, hence the
warning appears even though we aren't using that algorithm.

I see. Ok, that explains it for sure. I'll see if I can figure out how to silence the warning.

Thanks a lot, much obliged to you for digging.

Yves
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1008b
On Tue, 20 Feb 2018 00:06:57 -0800, shay wrote: Show quoted text
> I agree with Craig it's highly likely to be EOL problems - that's > surely the only reason that all those porting tests could be failing. > Make a new workspace like that and try again?
Explicitly setting core.autocrlf to 'false' instead of the default '' helped indeed. Thank you. Show quoted text
> Btw, what is the reason that you change the 'ar' entry in config.vc? I > never do that (though it would be nothing to do with the porting test > failures, obviously). Is that because of a limitation in the Community > Edition of Visual Studio?
There're some words about it in the readme, so I've changed it to what it suggests (maybe for some other compiler version?). I've tested a build without that change and it succeeded. So, now there're only IPC-under-harness failures and a lot of build warnings. Should I report them as a separate tickets for each on of the dist/ and ext/ modules, or this ticket is sufficient? As I've already reported them for all cpan/ ones.
CC: Perl5 Porters <perl5-porters [...] perl.org>
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
Subject: Re: [perl #132860] RFC on windows build status
Date: Wed, 21 Feb 2018 12:14:09 +0000
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.3k
On 20 February 2018 at 22:23, Sergey Aleynikov via RT <perlbug-followup@perl.org> wrote: Show quoted text
> On Tue, 20 Feb 2018 00:06:57 -0800, shay wrote:
>> I agree with Craig it's highly likely to be EOL problems - that's >> surely the only reason that all those porting tests could be failing. >> Make a new workspace like that and try again?
> > Explicitly setting core.autocrlf to 'false' instead of the default '' helped indeed. Thank you. >
>> Btw, what is the reason that you change the 'ar' entry in config.vc? I >> never do that (though it would be nothing to do with the porting test >> failures, obviously). Is that because of a limitation in the Community >> Edition of Visual Studio?
> > There're some words about it in the readme, so I've changed it to what it suggests (maybe for some other compiler version?). I've tested a build without that change and it succeeded.
That's in the section talking specifically about Microsoft Visual C++ Toolkit 2003. It shouldn't be necessary for any other version. Show quoted text
> > So, now there're only IPC-under-harness failures and a lot of build warnings. Should I report them as a separate tickets for each on of the dist/ and ext/ modules, or this ticket is sufficient? As I've already reported them for all cpan/ ones. >
I think this ticket is sufficient since dist/ and ext/ are maintained here by p5p anyway.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.1k
On Tue, 20 Feb 2018 06:45:46 -0800, demerphq wrote: Show quoted text
> hv_func.h correctly chooses STATDX, but it includes sbox32_hash.h just > before the choice is made. That includes zaphod32_hash.h, hence the > warning appears even though we aren't using that algorithm. > > > I see. Ok, that explains it for sure. I'll see if I can figure out how to > silence the warning. > > Thanks a lot, much obliged to you for digging. > > Yves
Every Win64 .o/XS module produces this warning described above, and stable perl can't ship if all XS module produce CC warnings in perl headers. --------------------------------- cl -c -I. -nologo -GF -W3 -O1 -MD -Zi -DNDEBUG -GL -fp:precise -DWIN32 -D_ CONSOLE -DNO_STRICT -DWIN64 -DCONSERVATIVE -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NON STDC_NO_DEPRECATE -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICI T_SYS -DWIN32_NO_REGISTRY -O1 -MD -Zi -DNDEBUG -GL -fp:precise -DVERSION=\"2. 074\" -DXS_VERSION=\"2.074\" "-I..\..\lib\CORE" -DBZ_NO_STDIO Bzip2.c Bzip2.c c:\p527\srcnew\lib\core\zaphod32_hash.h(221) : warning C4267: 'initializing' : c onversion from 'size_t' to 'U32', possible loss of data Bzip2.xs(488) : warning C4267: '=' : conversion from 'size_t' to 'unsigned int', possible loss of data --------------------------------- .i file output of problem line --------------------------------- static __inline U32 zaphod32_hash_with_state(const U8 * state_ch, const U8 * key, const STRLEN key_len) { U32 *state = (U32 *) state_ch; const U8 *end; STRLEN len = key_len; U32 v0 = state[0]; U32 v1 = state[1]; U32 v2 = state[2] ^ (0xC41A7AB1 * (key_len + 1));<<<<<<PROBLEM<<<<<<<<<<< ; #line 226 "c:\\p527\\srcnew\\lib\\core\\zaphod32_hash.h" ------------------------- Since this is Win64 key_len is 64 bit int, that is XORed with state[2] which is a U32 and the result is assigned to a U32, truncating high bytes. Hence the warning. It seems zaphod32_hash_with_state code is unique to you (demerphq) and not FOSS code borrowed from somewhere else, so there is no upstream to go consult about the truncation. -- bulk88 ~ bulk88 at hotmail.com
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 3.2k
On Wed, 21 Feb 2018 09:05:19 -0800, bulk88 wrote: Show quoted text
> Since this is Win64 key_len is 64 bit int, that is XORed with state[2] > which is a U32 and the result is assigned to a U32, truncating high > bytes. Hence the warning. It seems zaphod32_hash_with_state code is > unique to you (demerphq) and not FOSS code borrowed from somewhere > else, so there is no upstream to go consult about the truncation.
I see a bigger problem with the new hash code. I put a __builtin_trap() right before "U32 v2 = state[2] ^ (0xC41A7AB1 * (key_len + 1));" and did a "make test". It NEVER executed. I checked the machine code, and yes zaphod32_hash_with_state/__builtin_trap is linked in and I can see how theoretically executed, but it is unreachable in real life. zaphod32_hash_with_state is ONLY referenced by sbox32_hash_with_state. ------------------------------- static __inline U32 sbox32_hash_with_state(const U8 * state_ch, const U8 * key, const STRLEN key_len) { U32 *state = (U32 *) state_ch; U32 hash = *state; switch (key_len) { default: return zaphod32_hash_with_state(state_ch, key, key_len); case 24: -------------------------------- That is the only reference. But if I look at the callers of sbox32_hash_with_state, there are 18 callers, but all of then do the len <= 24 check. Example of usage. ------------------------------- static __inline U32 S_perl_hash_with_seed(const U8 * const seed, const U8 * const str, const STRLEN len) { U8 state[(32 + ((1 + (256 * 24)) * sizeof(U32)))]; do { stadtx_seed_state(seed, state); sbox32_seed_state96(seed + 16, state + 32); } while (0); return ((((len <= 24) ? (char) 1 : (char) 0)) ? sbox32_hash_with_state((state + 32), (U8 *) (str), (len)) : (U32) stadtx_hash_with_state(((state)), (U8 *) ((str)), ((len)))); } ------------------------------- So sbox32_hash_with_state can't be reached with a key longer than 24, yet sbox32_hash_with_state has a default: for a key longer than 24. The default: in sbox32_hash_with_state needs to be "NOT_REACHED;" and maybe an assert. That would remove zaphod32_hash_with_state() from the binary since on 64 bit OSes stadtx is used, not zaphod for long keys. I also think there is too much code not ifdefed out in hv_func.h sbox32_hash128 has no uses, it should be #if 0'ed so it doesn't reach the C->Asm stage. sbox32_seed_state128 whose only ref is sbox32_hash128 also can #if 0, since S_perl_hash_with_seed uses sbox32_seed_state96. sbox32_hash96 can also be if #0. S_perl_hash_siphash_2_4 S_perl_hash_siphash_2_4_with_state S_perl_hash_siphash_1_3 S_perl_hash_siphash_1_3_with_state S_perl_siphash_seed_state are also in the .i file event though perl is uses the PERL_HASH_USE_SBOX32_ALSO sbox/stadtx or sbox/zaphos pair. Those need ifdefs too. -- bulk88 ~ bulk88 at hotmail.com
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
Date: Thu, 22 Feb 2018 04:03:59 +0100
Subject: Re: [perl #132860] RFC on windows build status
CC: Perl5 Porteros <perl5-porters [...] perl.org>
From: demerphq <demerphq [...] gmail.com>
On 22 Feb 2018 03:04, "bulk88 via RT" <perlbug-followup@perl.org> wrote:
Show quoted text
On Wed, 21 Feb 2018 09:05:19 -0800, bulk88 wrote:
> Since this is Win64 key_len is 64 bit int, that is XORed with state[2]
> which is a U32 and the result is assigned to a U32, truncating high
> bytes. Hence the warning. It seems zaphod32_hash_with_state code is
> unique to you (demerphq) and not FOSS code borrowed from somewhere
> else, so there is no upstream to go consult about the truncation.

It is Foss, but it is also my work.😀

The truncation shouldn't matter, but it shouldn't throw an error either.

Show quoted text

I see a bigger problem with the new hash code. I put a __builtin_trap() right before "U32 v2 = state[2] ^ (0xC41A7AB1 * (key_len + 1));" and did a  "make test". It NEVER executed. I checked the machine code, and yes  zaphod32_hash_with_state/__builtin_trap is linked in and I can see how theoretically executed, but it is unreachable in real life.

This is a build option issue. Sbox hashing is very fast, but has a finite capacity, and falls through to zaphod32 when that capacity is exceeded. 

However with the way that we use sbox32 in perl we will do a similar fall through logic *before* we enter sbox32, but on 64 bit builds we will use stadtx64 instead of zaphod32.


Show quoted text

zaphod32_hash_with_state is ONLY referenced by sbox32_hash_with_state.

-------------------------------
static __inline U32
sbox32_hash_with_state(const U8 * state_ch,
                       const U8 * key, const STRLEN key_len)
{
    U32            *state = (U32 *) state_ch;
    U32             hash = *state;
    switch (key_len) {
    default:
        return zaphod32_hash_with_state(state_ch, key, key_len);

    case 24:
--------------------------------

That is the only reference.

But if I look at the callers of sbox32_hash_with_state, there are 18 callers, but all of then do the len <= 24 check. Example of usage.

Yep. You could change when this happens with the right -D to configure.

Show quoted text

-------------------------------
static          __inline U32
S_perl_hash_with_seed(const U8 * const seed, const U8 * const str,
                      const STRLEN len)
{
    U8              state[(32 + ((1 + (256 * 24)) * sizeof(U32)))];
    do {
        stadtx_seed_state(seed, state);
        sbox32_seed_state96(seed + 16, state + 32);
    } while (0);
    return ((((len <=
               24) ? (char) 1 : (char) 0)) ? sbox32_hash_with_state((state
                                                                     + 32),
                                                                    (U8
                                                                     *)
                                                                    (str),
                                                                    (len))
            : (U32) stadtx_hash_with_state(((state)), (U8 *) ((str)),
                                           ((len))));
}
-------------------------------
So sbox32_hash_with_state can't be reached with a key longer than 24, yet sbox32_hash_with_state has a default: for a key longer than 24. The default: in sbox32_hash_with_state needs to be "NOT_REACHED;" and maybe an assert. That would remove zaphod32_hash_with_state() from the binary since on 64 bit OSes stadtx is used, not zaphod for long keys.

Yep. Will do.

Show quoted text

I also think there is too much code not ifdefed out in hv_func.h

sbox32_hash128 has no uses, it should be #if 0'ed so it doesn't reach the C->Asm stage. sbox32_seed_state128 whose only ref is sbox32_hash128 also can #if 0, since S_perl_hash_with_seed uses sbox32_seed_state96. sbox32_hash96 can also be if #0.

S_perl_hash_siphash_2_4
S_perl_hash_siphash_2_4_with_state
S_perl_hash_siphash_1_3
S_perl_hash_siphash_1_3_with_state
S_perl_siphash_seed_state

are also in the .i file event though perl is uses the PERL_HASH_USE_SBOX32_ALSO sbox/stadtx or sbox/zaphos pair. Those need ifdefs too.

I assumed a good compiler would elide this unused code...

I'll dig further when I get a chance.

Thanks,
Yves

Show quoted text

--
bulk88 ~ bulk88 at hotmail.com

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=132860

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.9k
On Wed, 21 Feb 2018 19:04:12 -0800, demerphq wrote: Show quoted text
> On 22 Feb 2018 03:04, "bulk88 via RT" <perlbug-followup@perl.org> wrote: > > On Wed, 21 Feb 2018 09:05:19 -0800, bulk88 wrote:
> > Since this is Win64 key_len is 64 bit int, that is XORed with state[2] > > which is a U32 and the result is assigned to a U32, truncating high > > bytes. Hence the warning. It seems zaphod32_hash_with_state code is > > unique to you (demerphq) and not FOSS code borrowed from somewhere > > else, so there is no upstream to go consult about the truncation.
> > > It is Foss, but it is also my work.😀 > > The truncation shouldn't matter, but it shouldn't throw an error either.
Cast to U32 before assigning to U32 will quiet MSVC. Show quoted text
> However with the way that we use sbox32 in perl we will do a similar fall > through logic *before* we enter sbox32, but on 64 bit builds we will use > stadtx64 instead of zaphod32.
If you dont do the NOT_REACHED (I prefer that) more macros are needed so the inside of sbox32 matches the primary long key algo. Or have the primary long key algo only from the inside and make it so there is no way to use sbox32 for long keys. Show quoted text
> Yep. You could change when this happens with the right -D to configure.
Probably nobody ever will, but still, if the fallback is from inside sbox, then the fallback should only be from sbox, not from the outer _PERL_HASH_WITH_STATE. Basically sbox CANT be compiled to be used in isolation. Show quoted text
> Yep. Will do.
Yes please. Show quoted text
> I assumed a good compiler would elide this unused code...
A good linker will toss the code, a compiler CANT toss the code and had to spend CPU to generate ASM. Really bad linkers/bad OSes wont toss the code due to GOT/"debugging" reasons (call a static func explicitly with gdb). Show quoted text
> > I'll dig further when I get a chance.
A U32 cast is the quick and dirty way to fix it aslong as truncation is okay of that XOR, truncation is happening anyway on all 64b OSes whether a CC warns or not. -- bulk88 ~ bulk88 at hotmail.com
From: demerphq <demerphq [...] gmail.com>
Date: Sat, 24 Feb 2018 17:47:26 +0100
Subject: Re: [perl #132860] RFC on windows build status
To: Perl RT Bug Tracker <perlbug-followup [...] perl.org>
CC: Perl5 Porteros <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 2.4k
On 22 February 2018 at 06:34, bulk88 via RT <perlbug-followup@perl.org> wrote: Show quoted text
> On Wed, 21 Feb 2018 19:04:12 -0800, demerphq wrote:
>> On 22 Feb 2018 03:04, "bulk88 via RT" <perlbug-followup@perl.org> wrote: >> >> On Wed, 21 Feb 2018 09:05:19 -0800, bulk88 wrote:
>> > Since this is Win64 key_len is 64 bit int, that is XORed with state[2] >> > which is a U32 and the result is assigned to a U32, truncating high >> > bytes. Hence the warning. It seems zaphod32_hash_with_state code is >> > unique to you (demerphq) and not FOSS code borrowed from somewhere >> > else, so there is no upstream to go consult about the truncation.
>> >> >> It is Foss, but it is also my work.😀 >> >> The truncation shouldn't matter, but it shouldn't throw an error either.
> > Cast to U32 before assigning to U32 will quiet MSVC.
Done in: e5a551284a63f7f984d48babddbc0b25cf95058a Show quoted text
>
>> However with the way that we use sbox32 in perl we will do a similar fall >> through logic *before* we enter sbox32, but on 64 bit builds we will use >> stadtx64 instead of zaphod32.
> > If you dont do the NOT_REACHED (I prefer that) more macros are needed so the inside of sbox32 matches the primary long key algo. Or have the primary long key algo only from the inside and make it so there is no way to use sbox32 for long keys. >
>> Yep. You could change when this happens with the right -D to configure.
> > Probably nobody ever will, but still, if the fallback is from inside sbox, then the fallback should only be from sbox, not from the outer _PERL_HASH_WITH_STATE. Basically sbox CANT be compiled to be used in isolation.
Er... That isnt clear to me, but i trust you. I will look into reversing this somehow. For now the patch above will have to suffice. Show quoted text
>> Yep. Will do.
> > Yes please. >
>> I assumed a good compiler would elide this unused code...
> > A good linker will toss the code, a compiler CANT toss the code and had to spend CPU to generate ASM. Really bad linkers/bad OSes wont toss the code due to GOT/"debugging" reasons (call a static func explicitly with gdb). >
>> >> I'll dig further when I get a chance.
> > A U32 cast is the quick and dirty way to fix it aslong as truncation is okay of that XOR, truncation is happening anyway on all 64b OSes whether a CC warns or not.
Yeah, i did the cast. I will look into a more graceful fix another day. Thanks for you help, i will come back to you when i have further patches. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
RT-Send-CC: perl5-porters [...] perl.org
On Mon, 12 Feb 2018 12:47:07 -0800, randir wrote: Show quoted text
> - perlwin32.html (aka README.win32) states "There should be no test > failures.", but at least three tests failed for 64-bit build (console > window is by default too small, so I haven't recorded them) and I > ended up with cpan/IPC-Cmd/t/01_IPC-Cmd.t stuck (for at least 10 > minutes, until I've aborted it). Are those failures known? If not, > should I report them, or there're not enough volunteers to fix them, > so it's time to change the docs?
cpan/IPC-Cmd/t/01_IPC-Cmd.t hangs/failures with Windows 7 (I dont see it on XP) random/race failures are caused by perl calling closesocket() on non-sockets I've talked about it at https://rt.perl.org/Ticket/Display.html?id=118127 Win 7-32bit callstack of frozen with under-harness 01_IPC-Cmd.t, perl's curcop is at https://perl5.git.perl.org/perl.git/blob/c4a2ac437ed67b458e466f3724f82c10afc3eb40:/dist/IO/lib/IO/Handle.pm#l379 ----------------------------------- ntdll.dll!_KiFastSystemCallRet@0() Unknown ntdll.dll!_ZwDeviceIoControlFile@40() Unknown mswsock.dll!_SockImportHandle@12() Unknown mswsock.dll!_SockFindAndReferenceSocket@8() Unknown mswsock.dll!_WSPGetSockOpt@24() Unknown ws2_32.dll!DCATALOG::FindIFSProviderForSocket(unsigned int) Unknown ws2_32.dll!DSOCKET::FindIFSSocket(unsigned int) Unknown ws2_32.dll!_closesocket@4() Unknown perl527.dll!my_close(int fd) Line 696 C perl527.dll!PerlIOUnix_close(interpreter * my_perl=0x000f2e8c, _PerlIO * * f=0x024441dc) Line 2816 C perl527.dll!PerlIOBase_close(interpreter * my_perl=0x000f2e8c, _PerlIO * * f=0x00105c24) Line 2132 C perl527.dll!PerlIOBuf_close(interpreter * my_perl=0x000f2e8c, _PerlIO * * f=0x00105c24) Line 4257 C perl527.dll!Perl_PerlIO_close(interpreter * my_perl=0x000f2e8c, _PerlIO * * f=0x00105c24) Line 1373 C perl527.dll!S_openn_cleanup(interpreter * my_perl, gv * gv, io * io=0x0010f7b4, _PerlIO * * fp=0x00105c24, char * mode=0x0031f698, const char * oname=0x02361f2c, _PerlIO * * saveifp=0x001059b4, _PerlIO * * saveofp=0x00105c0c, int savefd=0x00000002, char savetype='s', int writing=0x00000001, char was_fdopen='\0', const char * type=0x00000000, _stat64 * statbufp=0x00000000) Line 1024 C perl527.dll!Perl_do_open6(interpreter * my_perl, gv * gv, const char * oname=0x02361f2c, unsigned int len=0x00000013, _PerlIO * * supplied_fp=0x00000000, sv * * svp=0x00ab1580, unsigned long num_svs=0x00000000) Line 876 C perl527.dll!Perl_pp_open(interpreter * my_perl=0x00000000) Line 640 C perl527.dll!Perl_runops_standard(interpreter * my_perl=0x000f2e8c) Line 41 C perl527.dll!S_run_body(interpreter * my_perl, long oldscope) Line 2755 C perl527.dll!perl_run(interpreter * my_perl=0x000f2e8c) Line 2671 C perl527.dll!RunPerl(int argc=0x00000004, char * * argv=0x000eeab0, char * * env=0x000ef540) Line 252 C++ perl.exe!__tmainCRTStartup() Line 626 C kernel32.dll!@BaseThreadInitThunk@12() Unknown ntdll.dll!___RtlUserThreadStart@8() Unknown ntdll.dll!__RtlUserThreadStart@8() Unknown ----------------------------------- -- bulk88 ~ bulk88 at hotmail.com
Subject: Re: [perl #132860] RFC on windows build status
Date: Sat, 24 Feb 2018 22:13:30 -0700
To: perl5-porters [...] perl.org
From: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 1.5k
On 02/12/2018 01:47 PM, Sergey Aleynikov (via RT) wrote: Show quoted text
> # New Ticket Created by Sergey Aleynikov > # Please include the string: [perl #132860] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=132860 > > > > This is a bug report for perl from sergey.aleynikov@gmail.com, > generated with the help of perlbug 1.41 running under perl 5.27.9. > > > ----------------------------------------------------------------- > [Please describe your issue here] > > I've recently done a Perl build on a Windows machine using VS 2017 and > found it's status a bit alarming: > > - perlwin32.html (aka README.win32) states "There should be no test > failures.", but at least three tests failed for 64-bit build (console > window is by default too small, so I haven't recorded them) and I > ended up with cpan/IPC-Cmd/t/01_IPC-Cmd.t stuck (for at least 10 > minutes, until I've aborted it). Are those failures known? If not, > should I report them, or there're not enough volunteers to fix them, > so it's time to change the docs? > > - during both 32-bit and 64-bit builds, I've seen a lot of warnings > about variables size mismatch conversions (in both ways). Most of them > seem to have the same underlying source, but they're really numerous. > > Or is windows build currently supported only as a MinGW Strawberry > build by it's community?
On the Windows attached to dromedary (I presume it's a VM), the build now hangs in the trying to probe the Storable stack size. This means that blead can not be run on this machine until this is fixed
To: perl5-porters [...] perl.org
Date: Sat, 24 Feb 2018 22:17:26 -0700
Subject: Re: [perl #132860] RFC on windows build status
From: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 1.6k
On 02/12/2018 01:47 PM, Sergey Aleynikov (via RT) wrote: Show quoted text
> # New Ticket Created by Sergey Aleynikov > # Please include the string: [perl #132860] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=132860 > > > > This is a bug report for perl from sergey.aleynikov@gmail.com, > generated with the help of perlbug 1.41 running under perl 5.27.9. > > > ----------------------------------------------------------------- > [Please describe your issue here] > > I've recently done a Perl build on a Windows machine using VS 2017 and > found it's status a bit alarming: > > - perlwin32.html (aka README.win32) states "There should be no test > failures.", but at least three tests failed for 64-bit build (console > window is by default too small, so I haven't recorded them) and I > ended up with cpan/IPC-Cmd/t/01_IPC-Cmd.t stuck (for at least 10 > minutes, until I've aborted it). Are those failures known? If not, > should I report them, or there're not enough volunteers to fix them, > so it's time to change the docs? > > - during both 32-bit and 64-bit builds, I've seen a lot of warnings > about variables size mismatch conversions (in both ways). Most of them > seem to have the same underlying source, but they're really numerous. > > Or is windows build currently supported only as a MinGW Strawberry > build by it's community?
I've wondered about the common warning message from the Windows compiler to the effect that we should be using sprintf_s() and gmtime_s() (for example) instead of what we are using. How do these differ from various reentrant foo_r() functions that we automatically use if available?
From: Karl Williamson <public [...] khwilliamson.com>
To: perl5-porters [...] perl.org
Subject: Re: [perl #132860] RFC on windows build status
Date: Sun, 25 Feb 2018 11:42:27 -0700
Download (untitled) / with headers
text/plain 1.7k
On 02/24/2018 10:13 PM, Karl Williamson wrote: Show quoted text
> On 02/12/2018 01:47 PM, Sergey Aleynikov (via RT) wrote:
>> # New Ticket Created by  Sergey Aleynikov >> # Please include the string:  [perl #132860] >> # in the subject line of all future correspondence about this issue. >> # <URL: https://rt.perl.org/Ticket/Display.html?id=132860 > >> >> >> This is a bug report for perl from sergey.aleynikov@gmail.com, >> generated with the help of perlbug 1.41 running under perl 5.27.9. >> >> >> ----------------------------------------------------------------- >> [Please describe your issue here] >> >> I've recently done a Perl build on a Windows machine using VS 2017 and >> found it's status a bit alarming: >> >> - perlwin32.html (aka README.win32) states "There should be no test >> failures.", but at least three tests failed for 64-bit build (console >> window is by default too small, so I haven't recorded them) and I >> ended up with cpan/IPC-Cmd/t/01_IPC-Cmd.t stuck (for at least 10 >> minutes, until I've aborted it). Are those failures known? If not, >> should I report them, or there're not enough volunteers to fix them, >> so it's time to change the docs? >> >> - during both 32-bit and 64-bit builds, I've seen a lot of warnings >> about variables size mismatch conversions (in both ways). Most of them >> seem to have the same underlying source, but they're really numerous. >> >> Or is windows build currently supported only as a MinGW Strawberry >> build by it's community?
> > On the Windows attached to dromedary  (I presume it's a VM), the build > now hangs in the trying to probe the Storable stack size.  This means > that blead can not be run on this machine until this is fixed >
This is working again; perhaps it was my fault somehow.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org