Re: "make check" failure on Solaris 10 with make 4.2.91

[Paul Smith]

On Mon, 2019-09-16 at 12:23 -0700, Paul Eggert wrote:
> > Can you run this and tell me what it prints:
> > 
> >    perl -we 'use File::Spec::Functions qw(splitpath); my @o =
> splitpath("../make"); print "@o\n"'
> 
> A single line " ../make".

Ugh, that's wrong.  It should be " ../ make" (note the space before
"make").  File::Spec is not correctly splitting the directory from the
file, apparently.  Bogus!!  Can you try this one:

  perl -we 'use File::Spec; my @o = File::Spec->splitpath("../make"); print 
"@o\n"'

and see what that says?

> > and also this:
> > 
> >    perl -we 'use File::Spec; print "$File::Spec::VERSION\n";'
> 
> A single line "0.87".

Hm.  This should be OK.  I must admit I'm not really familiar with the
full history of File::Spec and what was/wasn't supported.

Regarding your errors:

I'm not sure about the output-sync tests.  Could be timing, could be
something else.  I'd be a little surprised if it was timing; I thought
I had made those timeouts more than long enough; they're supposed to
just be sanity checks.  If you want you can up them by changing:

  $tmout = 30;

in tests/scipts/features/output-sync.

The vpathplus difference is due to endian issues; our hash function
returns a different order between big/little endian.  There's a patch
out there to test this in Perl and adjust the expected output.  I'm
still thinking about it.

The wildcard one is probably because Solaris struct dirent doesn't have
a d_type field, or else autoconf can't find it.  Google makes me
suspect the former.

In that situation our current glob library just doesn't try to tell the
difference between files and directories, rather than falling back to
an explicit stat() or something, and so some of these wildcard tests
fail.  I may not fix this before the 4.3 release... it's not a
regression; these tests would fail with the 4.2.1 release as well.  I
may wait until the next release and pull in the latest gnulib glob code
instead of continuing to keep a local, old and crusty version.

The downside is gnulib glob yanks in A LOT of extra stuff and that
makes the non-POSIX ports (native Windows, VMS, DOS, etc.) much more
difficult.  Maybe I should keep the old glob code for those platforms. 
Hm.