Build fails on Windows 10 using Cygwin tool chain

[blues1875]

I recently built perl 5.36 on Windows 10 using the tool chain from Strawberry Perl 5.32. On building Module-Find 0.15, I see the following errors:

#   Failed test at t/07-symlinks.t line 21.
Use of uninitialized value $l[0] in string eq at t/07-symlinks.t line 22.

#   Failed test at t/07-symlinks.t line 22.

#   Failed test at t/07-symlinks.t line 25.
Use of uninitialized value $l[0] in string eq at t/07-symlinks.t line 26.

#   Failed test at t/07-symlinks.t line 26.
Use of uninitialized value $l[1] in string eq at t/07-symlinks.t line 27.

#   Failed test at t/07-symlinks.t line 27.

#   Failed test at t/07-symlinks.t line 42.
Use of uninitialized value $l[0] in string eq at t/07-symlinks.t line 43.

#   Failed test at t/07-symlinks.t line 43.

#   Failed test at t/07-symlinks.t line 46.
Use of uninitialized value $l[0] in string eq at t/07-symlinks.t line 47.

#   Failed test at t/07-symlinks.t line 47.
Use of uninitialized value $l[1] in string eq at t/07-symlinks.t line 48.

#   Failed test at t/07-symlinks.t line 48.
# Looks like you failed 10 tests of 13.

The module builds with no problem using Strawberry Perl 5.32. Dependant module versions were:

Checking if you have File::Spec 0 ... Yes (3.84)
Checking if you have File::Find 0 ... Yes (1.40)
Checking if you have Test::More 0 ... Yes (1.302190)

[blues1875]

I think this is related to a recent change in File::Find. See simonwistow/Module-Pluggable#24

[crenz]

Thanks for alerting me to this. Given the discussion in Perl/perl5#20008, I think there are two possible solutions:

1. Also skip the test if symlink returns 0 (i.e., creation of symlinks is not allowed)

2. Introduce a Windows-specific check (using $Config{d_symlink}, Win32::IsSymlinkCreationAllowed() as outlined by xenu)

I would prefer going for 1) as it is the more simple solutions. Any comments, @sisyphus, @xenu?

[sisyphus]

Also skip the test if symlink returns 0 (i.e., creation of symlinks is not allowed)

The devil is firstly that you have to allow for the possibility that calling symlink() will throw an exception and abort the test script.
Secondly, if it didn't throw an exception, then you need to know whether it returned 0 or 1.
Thirdly, (on Windows, at least), if it returned 0, then you need to know that it returned 0 because symlink creation is unsupported (as opposed to some other reason).

You could perhaps avoid that third consideration. I suppose that if 0 was returned you could just skip the tests in 07-symlinks.t on the assumption that they are going to be un-runnable irrespective of the actual cause of the failure.

I would prefer @xenu's approach because it's more broadly applicable, and avoids using eval.
Something like the following patch (which tests fine for me) :

--- t/07-symlinks.t_orig	2022-07-28 23:25:20 +1000
+++ t/07-symlinks.t	2022-07-30 12:19:18 +1000
@@ -1,5 +1,6 @@
 use strict;
 use warnings;
+use Config;
 
 use Test::More tests => 13;
 
@@ -11,8 +12,20 @@
 my $linkName = "./t/test/ModuleFindTestSymLink";
 
 SKIP: {
-    eval { symlink($dirName, $linkName) };
-    skip "Symlinks not supported on this system", 13 if $@;
+
+    my $can_create_symlinks = sub {
+        return 0 if !$Config{d_symlink};
+
+        if ($^O eq 'MSWin32') {
+            require Win32;
+            return Win32::IsSymlinkCreationAllowed();
+        }  
+        else {
+            return 1;
+        }
+    }->();
+
+    skip "Symlinks not supported on this system", 13 unless $can_create_symlinks;
 
     my @l;

But use of symlink() is do-able, if you prefer that approach.

I should point out that I haven't actually tested the above patch in an environment that enables creation of symlinks.

Cheers,
Rob

[crenz]

Thanks for the quick feedback, @sisyphus! My issue with @xenu's approach is twofold: First, Module::Find has been around for a really long time and I aim to be backwards compatible with older Perl versions where feasible. Second, the solution depends on some details of Perl on Windows systems that I am not able to test myself (lacking access to suitable systems).

OTOH, if the test file fails to create the symlink, the tests will fail anyway. The fact that so far I didn't check the result of symlink() can be considered a bug. So I will probably go with this approach (as outlined in commit 9a5e343).

[sisyphus]

So I will probably go with this approach (as outlined in commit 9a5e343)

Yep - that should be fine for your purposes, and tests ok for me.

I've tested @xenu's approach on Windows as far back as perl-5.8.8, and it works fine.
I didn't test it on every version all the way back to 5.8.8 - and I don't see any need to do so.

I even tested Module-Find-0.15 on Windows perl-5.6.2. It failed quite a few tests.
t/07-symlinks.t correctly skipped all tests - but many other scripts failed with:

t\02-find.................The stat preceding -l _ wasn't an lstat at C:/Perl_M/lib/File/Find.pm line 252.
# Looks like your test died before it could output anything.

But that would better be looked at in a new issue if you're wanting to pursue it.
AFAICT that particular version of File::Find didn't even have a version number.

Note that, with @xenu's approach, Win32::IsSymlinkCreationAllowed() will only ever be called if it's available - which is on Windows perl-5.34 and later. Otherwise, on Windows, his anonymous sub will always return a false value because $Config{d_symlink} is false.

It's a pity that Strawberry Perl development has been in hiatus since perl-5.32.1 was released. If not for that, we would have found out about this issue well over a year ago.
Anyway ... it's great that you've attended to this so quickly after becoming aware of it !!

Cheers,
Rob

[blues1875]

I'm still trying to keep up with all this, but I think the problem may be a little deeper than just the tests. When I run the one-liner:

perl -MModule::Find -e "print join \"\n\", findsubmod DBI;"

on perl 5.32, I get a list of DBI modules. When I run the same one-liner on 5.36, I get nothing. If I change the line in Module-Find:

our $followMode = 1;

to

our $followMode = 0;

then I get the same list of modules. This is on Windows 10 with Module-Find built by short-circuiting 07-symlinks.t.

Again, this seems to be pointing the finger at File-Find.

[crenz]

Thanks for investigating, @blues1875. Did you use the stock File::Find module shipped with 5.36, or did you apply the fix in Perl/perl5#20008?

This matches the weirdness I am seeing in my test results: In 5.32, symlinkreturns 0and the tests are skipped. In 5.36, I am actually able to create a symlink – at least symlink does not return 0, and -l reports true (in a newly introduced test). But the test runs fail because the module does not seem to find the modules behind the symlink.

@sisyphus: I bumped the minimum version required to 5.8.1. Thanks for catching that. 5.6.1 support was broken for a while. I guess it could be made to work if really necessary.

[blues1875]

Good point! That was using the stock File::Find. When I apply the patch, it works as expected. The 07-symlinks.t test still fails, but when I apply your fix to that, it passes too.