Task::Kensho install failures. #103
Comments
|
|
The current Strawberry 5.36.1 builds disable symlinks due to test failures of other modules. It would seem lib::relative needs to modify its skip checks in that test, perhaps adapting the code in Path::Tiny The solution/workaround for now is to install it as part of the build process, skipping that test file. |
|
See also #67 for the list of known symlink issues in the build, some of which only manifest on the docker instance. |
|
MCE is also failing. Edit: |
|
|
|
I think I'll re-enable the symlinks in the builds and update the test skips as needed. Most of the issues only manifest under docker. |
|
So I force installed
Later edits for additional modules:
|
|
It then hangs on Edit - this looks to be a long standing issue: https://rt.cpan.org/Public/Bug/Display.html?id=82542 |
I'm happy to modify the tests if that would help. Would you mind opening an issue at https://github.com/Grinnz/lib-relative/issues |
Thanks @book. I've opened an issue. |
|
The If so then maybe more alignment checks are needed, possibly in perl and possibly in the modules? @sisyphus - are you able to replicate the MCE and File::NFSLock failures on your builds of 5.36 and 5.37? |
|
MCE fails for me on both x64 perl-5.36 (gcc-11.3.0) and perl-5.37(gcc-12.2.0, gcc-13.1.0), but there's no problem with building MCE on the x86 builds of 5.36 and 5.37 that I've tried. Here's what I get on the x64 builds: Most of those failing test scripts are ones that hung, and were then terminated by me using Process Explorer. OTOH File::NFSLock seems to throw up the same errors on both 32-bit and 64-bit perls, so I think the problem there is likely a different issue. All of the t/*fork_ex.t and t/*fork_sh.t files fail their final test for me. AIUI, none of the segfaulting modules that weren't fixed by the vmem.h patch have been fixed .... so what's needed is rather speculative. With my MSVC builds (Visual Studio 2022) of perl, MCE and File::NFSLock behave in pretty much the same way as they do on the mingw-w64 builds. Cheers, |
|
The https://metacpan.org/dist/MCE/source/lib/MCE/Util.pm#L284 my $val_bytes = "\x00\x00\x00\x00";
my $ptr_bytes = unpack('I', pack('P', $val_bytes));
ioctl($socket, 0x4004667f, $ptr_bytes);MCE will not work on the Windows platform my $val_bytes = pack('L', 0);
ioctl($socket, 0x4004667f, $val_bytes); # FIONREAD
return '' if unpack('L', $val_bytes);Some tests are still failing. Looking deeper. |
|
With the ioctl issue resolved locally, all MCE tests pass and zero failures. However, I do not understand the non-zero exit status: 5. |
|
I am delighted to report the next MCE 1.885 and MCE::Shared 1.881 updates pass running Perl 5.36.1.1 64-bit portable edition. |
|
MCE 1.885 and MCE::Shared 1.881 have been released.
The root cause, in the case of MCE, is |
|
Thanks again @marioroy MCE and MCE::Shared now pass all tests with the current dev version of SP5.36.1. |
|
@shawnlaffan. I did a couple of changes and thought to track down which is it that resolved the issue or both. Item 1 was done first followed by item 2. Earlier testing:
Summary:
|
Both 'int' and 'long' are always 32 bits on both Win32 && Win64 - so I think no change is to be expected. Interestingly, the If that is to believed, and Do I misunderstand something ? In any case, execellent work @marioroy !! Cheers, |
I apologize for the confusion. Initially, I changed from I to L and not yet item 2 during earlier testing. Item 2 (passing a pointer to ioctl) is the sole reason, in the case of MCE, tests failing running Strawberry Perl 5.36.1.1. # not okay
my $val_bytes = pack('L', 0);
my $ptr_bytes = unpack('L', pack('P', $val_bytes));
ioctl($socket, 0x4004667f, $ptr_bytes); # MSWin32 FIONREAD, segfault/IPC hang
# okay, I or L
my $val_bytes = pack('L', 0);
ioctl($socket, 0x4004667f, $val_bytes); # MSWin32 FIONREAD# not okay
my $nonblocking = $_[1] ? pack('L', 1) : pack('L', 0);
my $ptr_bytes = unpack('L', pack('P', $nonblocking));
ioctl($socket, 0x8004667e, $ptr_bytes); # MSWin32 FIONBIO, segfault/IPC hang
# okay, I or L
my $nonblocking = $_[1] ? pack('L', 1) : pack('L', 0);
ioctl($socket, 0x8004667e, $nonblocking); # MSWin32 FIONBIO |
String::Escape has Makefile.PL extras that cause infinite loops. Remove those as they are for development not building. Test::MockObject t/extends.t failures are probably related to Portable.pm and have been reported upstream. Updates #103
|
The question is whether we try to patch 5.36.1 (if we can locate the correct patches) or leave them as known issues. |
@shawnlaffan, Is it important that they pass for me, too ? ... or is the fact that they build ok for you in your development environment all that really matters ? File::Next does not install cleanly for me on Windows 11 with SP-5.38.0.1-RC1: lib::relative also fails in a similar way: as, too, does Specio::Library::Path::Tiny : I guess there might be things I could do to my build environment that would allow those tests to pass but, ideally, I think those tests scripts should detect the incapacity in my environment, and skip those failing tests. Cheers, |
Thanks for checking. The 5.38 checks I ran were on the build system (on a docker instance). I'll check with a downloaded version on a local drive but would not be surprised if the failures arose again. If that's the case then the tests still need updating/skipping. |
|
The items in the list of issues in #103 (comment) are now either resolved, skipped or not a Strawberry Perl problem. I'll close this issue now. If new problems or solutions are identified then they can be raised as new issues. |
One of the easiest way to test things is to look at any failures Task::Kensho presents.
Using https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/dev_5.36.1_20230528_gcc13 results in the following install failures:
The text was updated successfully, but these errors were encountered: