building Perl 5.42.0 fails on Windows with `USE_ITHREADS=undef` configuration

[shogo82148]

Description

Building Perl 5.42.0 fails on Windows with USE_ITHREADS=undef configuration.

Here is my build log: https://gist.github.com/shogo82148/c2ded250adc246150e080fd5d842bb09

Steps to Reproduce

Run the following script on windows:

curl -O https://cpan.metacpan.org/authors/id/B/BO/BOOK/perl-5.42.0.tar.gz
tar xzvf perl-5.42.0.tar.gz
cd perl-5.42.0/win32
gmake SKIP_CCHOME_CHECK=1 USE_ITHREADS=undef

You can reproduce on GitHub Actions:

name: perl

on:
  workflow_dispatch:

jobs:
  setup-perl:
    runs-on: "windows-latest"
    steps:
      - run: |
          curl -O https://cpan.metacpan.org/authors/id/B/BO/BOOK/perl-5.42.0.tar.gz
          tar xzvf perl-5.42.0.tar.gz
          cd perl-5.42.0/win32
          gmake SKIP_CCHOME_CHECK=1 USE_ITHREADS=undef
        shell: bash

https://github.com/shogo82148/github-action-test/blob/8494862465fb4ab1dba2c6254817b750135698da/.github/workflows/perl.yaml

https://github.com/shogo82148/github-action-test/actions/runs/16336816810

Expected behavior

The build passes

Perl configuration

not available.

[richardleach]

This looks like the errors #23178 is intended to fix.

[sisyphus]

gmake SKIP_CCHOME_CHECK=1 USE_ITHREADS=undef

If it helps, when I build unthreaded perls on Windows I specify USE_MULTI=undef USE_ITHREADS=undef USE_IMP_SYS=undef, and that works fine.
But, of course, that's not going to be of much use to you if you want USE_MULTI and/or USE_IMP_SYS to remain defined.

[bulk88]

# uncomment to enable multiple interpreters.  This is needed for fork()
# emulation and for thread support, and is auto-enabled by USE_IMP_SYS
# and USE_ITHREADS below.
#
USE_MULTI	:= define

#
# Interpreter cloning/threads; now reasonably complete.
# This should be enabled to get the fork() emulation.  This needs (and
# will auto-enable) USE_MULTI above.
#
USE_ITHREADS	:= define

#
# uncomment to enable the implicit "host" layer for all system calls
# made by perl.  This is also needed to get fork().  This needs (and
# will auto-enable) USE_MULTI above.
#
USE_IMP_SYS	:= define

not going to research all 2^3=8 permutations, but note, the makefile has logic prohibiting certain permutations if you build the perl by editing the makefile vs command line options, i forgot if in MKF lang, cmd arg defines uncontrollable override if/else logic and override the ability of the MKF to redefine a macro against the user's wishes on the cmd line

[jkeenan]

This looks like the errors #23178 is intended to fix.

@richardleach, @shogo82148 , that p.r. was merged into blead last week. Would you be able to build a perl on Windows at that commit or later and let us know whether that resolves the problem in this ticket? Thanks.

[sisyphus]

Would you be able to build a perl on Windows at that commit or later and let us know whether that resolves the problem in this ticket?

As I mentioned above, I normally do my unthreaded builds by specifying command line args USE_MULTI=undef USE_ITHREADS=undef USE_IMP_SYS=undef.

With current blead (commit e31d3ed) I've tried doing an unthreaded build, having altered the third of those options to USE_IMP_SYS=define.

With both MSVC143 and gcc-15.1.0, the build croaks on the symbol PerlDir_read.

With MSVC143:

bsd_glob.c
bsd_glob.c(798): error C2065: 'PerlDir_read': undeclared identifier

With gcc-15.1.0:

bsd_glob.c: In function 'glob3':
..\..\lib\CORE/XSUB.h:516:33: error: 'PerlDir_read' undeclared (first use in this function) ....

Am I expected to also define 'USE_MULTI' ? ... or what ?

[sisyphus]

Am I expected to also define 'USE_MULTI' ?

I tried defining 'USE_MULTI' as well, and that worked much better.
Both builds failed /cpan/Win32/t/GetCurrentThreadId.t :

../cpan/Win32/t/GetCurrentThreadId.t                               (Wstat: 65280 (exited 255) Tests: 1 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 4 tests but ran 1.

A bug in the test script, perhaps ?
UPDATE: cpan/Win32/t/GetCurrentThreadId.t thinks that the presence of PERL_IMPLICIT_SYS in ccflags is sufficient to guarantee fork() capability - and that's no longer so.
It would be better to examine $Config{useithreads} for definedness.

[sisyphus]

I was about to submit a PR to the perl5 repo, but then realized that the problem was with one of those PITA dual-life modules.
So I've submitted the PR to perl-libwin32/win32#45.

The automated testing of that PR has failed due to (what appears to me to be) bitrot.
So I don't know when (if ever) the proposed fix will filter through to blead.
FWIW, it seems to me that this issue is closable.

[bulk88]

I was about to submit a PR to the perl5 repo, but then realized that the problem was with one of those PITA dual-life modules. So I've submitted the PR to perl-libwin32/win32#45.

You wasted your time writing a patch JKJK

The automated testing of that PR has failed due to (what appears to me to be) bitrot. So I don't know when (if ever) the proposed fix will filter through to blead. FWIW, it seems to me that this issue is closable.

Someone (PSC/Pumpking/CPAN Toolchain Gang) needs to ask Jan Dubois to transfer COMAINT of https://github.com/Perl/perl5/blob/blead/cpan/Win32/Win32.pm . I'm am volunteering to do maint for Win32.pm if someone offers it me and I wold massively clean up the bug list and stalled PRs sitting on that GITHUB and drop the ticket list to zero. I would like to be connected to a frequently around, hi kno how 2nd maintainer to review my fixes and improvements before I ship them as stable. And someone to brainstorm there when minor problems come up of slightly difficultly regarding "Use Solution A or Solution B? come up and bulk88 is stuck in design phase.

Its been 3 or 4 years since JDB last looked at libwin32's Github Tracker. He also haisn't been active anywhere else in Perl for the same time period.

He makes daily GH commits for another non-Perl framework/company. 5.42.0 was shipped with a emergency patched Win32.pm with a SHA1 override. Win32.pm is too critical of a module for perl.exe to have an inactive or retired maintainer.

The Win32.xs TU and auto/Win32/Win32.dll file are the one and only way to get the CWD on WinPerl. PP Cwd.pm's backend for Windows lives inside auto/Win32/Win32.dll.

miniperl.exe has a secret miniperl-only API inside of itself to get the CWD on Windows.

https://github.com/Perl/perl5/blob/blead/universal.c#L1344

I added that code a long time ago because of writing on the wall that Win32.xs has big maintenance problems since ActiveState/MS lost commercial interest in WinPerl in the early aughts. I have no idea if miniperl.exe's code works on Unix/VMS/ZOS/OS2/Symbian/Cray and it doesn't matter for me. Unix miniperl has very little participation in compiling full perl because Awk and M4 are Turing complete languages identical to Perl. nmake and gmake are not Turing complete.

This ship has sailed long ago, but if I was around in 1995 or 1996 I would've never picked WinPerl's current build architecture. The right tool to use to build WinPerl wouldve been JavaScript https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wscript

AFAIK all clean-installs of all versions of Windows have WSH. I've never seen a Windows install without WSH. I would assume there would political outrage over a .js file being inside the p5p/.git repo but thats a bridge to cross when the time comes.

Win32.xs is a synonym for Kernel32.pm. Your not starting a process on Windows without linking to Kernel32.pm, Kernel32.xs, Kernel32.js, or Kernel32.pyd, or Kernel32.pecl'

From day 1 1996 to Until 2003 Win32,xs was called Win32,c it was written in raw XS C code, no help from EUPXS,And it was static linked into perldll5xx.dl whether you wanted it or not, Think the builtin modules and mro:: modules,

Active State rightsfully asks to split to CPAN, because P5P at the time already had announced this project is scheduled to close Go try our friend perl 6 https://web.archive.org/web/20150205231803/http://perl6.org/ and 5.005 threads to 5.6 transition, and the 5 years time between 5.8 to 10.0, was a good reason to move all .c.files off onto Cpan volunteers., since they are much more resposive to fixing bugs and shipping tarballs than P5P commit bit people were. Butfor the last 20 years, the reverse happened,Win32.pm` just rotted away. My PR on its GH are now 14 years old and unanswered,

Someone hash to change

[shogo82148]

Would you be able to build a perl on Windows at that commit or later and let us know whether that resolves the problem in this ticket? Thanks.

It makes my build happy. thanks.