Re: a coreutils release is imminent

[Jim Meyering]

Matthew Woehlke <address@hidden> wrote:
...
> This is looking to be the best coreutils yet (nice work on getting
> Darwin clean!), but it still fails to pass 'make check' on four of my
> platforms...

Thanks for all the testing.
>
> OVERVIEW:
> ---------
>
> sparc-sun-solaris2.10      OK
> sparc-sun-solaris2.7     OK
> i386-pc-solaris2.10        OK
> i686-pc-linux-gnu          OK (linux 2.4.21-20.ELsmp, glibc 2.3.2-95.27)
> x86_64-unknown-linux-gnu   OK (linux 2.4.21-37.ELsmp, glibc 2.3.2-95.37)
> ia64-unknown-linux-gnu     OK (linux 2.4.18-e.27smp,  glibc 2.2.4-32.11)
> ia64-hp-hpux11.22          FAIL (sort-compress*)
> hppa2.0w-hp-hpux11.00      OK
> powerpc-ibm-aix5.1.0.0     BUILD FAILURE (lib/xstrndup)

Looks like Bruno has just fixed that in gnulib.

> powerpc-apple-darwin8.8.0  OK
> i386-apple-darwin8.8.1     OK
> mips-sgi-irix6.5           FAIL (tty-eof)

I've investigated this enough to be pretty confident it is solely
a problem in that particular test script, maybe in Expect.pm.

> alphaev56-dec-osf4.0g      FAIL

What version of Perl do you have there?

> nsr-tandem-nskG06          I wish :-)
>
> NOTE: All tests were run as non-root on an NFS volume. chgrp tests were
> skipped.
>
> (*...ate my buffer, so I can't tell what else, if anything, failed. I
> will re-run tomorrow and follow up with a more verbose report.)
>
>
> FAILURES:
> ---------
>
> I have *NO* c99-compatible compiler on sparc/Solaris, at least configure
> is not detecting it properly. This includes the most recent one I have
> available, 'cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15'! It looks
> suspiciously like my compiler may be broken.

No problem.  Just apply the c99-to-c89 patch.

> sort-compress still fails with a low process limit (e.g. my OSF
> system)... I thought this was fixed? It also failed on ia64/hpux.
>
> There is (still) a really annoying problem with the perl detection that
> leads to "can't find strict.pm" problems; maybe we could check that perl

This is the first I've heard of such a problem.
What version of Perl is installed there?
I may simply raise the required version number to one for which
"use strict;" works.  In the mean time, you can work around that
by manually removing the "use strict" lines.

> is *usable*, not just if it exists? Because of this it isn't clear how
> many test failures are spurious. (It's also unfortunate that so many
> tests need perl; perl isn't fun to build... so far every time I've
> considered trying it I've given up.) For now I'm not even going to try
> to chase the OSF test failures, this needs to be addressed first.

No big deal.
Very few people depend on OSF-based systems for real work.
Especially 4.0, since it's so buggy.