[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a coreutils release is imminent
From: |
Jim Meyering |
Subject: |
Re: a coreutils release is imminent |
Date: |
Wed, 21 Mar 2007 08:27:51 +0100 |
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.
- a coreutils release is imminent, Jim Meyering, 2007/03/20
- Re: a coreutils release is imminent, Matthew Woehlke, 2007/03/20
- Re: a coreutils release is imminent, Bob Proulx, 2007/03/21
- Re: a coreutils release is imminent,
Jim Meyering <=
- Re: a coreutils release is imminent, Matthew Woehlke, 2007/03/21
- Re: a coreutils release is imminent, Matthew Woehlke, 2007/03/21
- Re: a coreutils release is imminent, Jim Meyering, 2007/03/21
- Re: a coreutils release is imminent, Matthew Woehlke, 2007/03/21
- Re: a coreutils release is imminent, Andreas Schwab, 2007/03/21
- Re: a coreutils release is imminent, Matthew Woehlke, 2007/03/21
- Re: a coreutils release is imminent, Jim Meyering, 2007/03/21
- Re: a coreutils release is imminent, Matthew Woehlke, 2007/03/21
- Re: a coreutils release is imminent, Paul Eggert, 2007/03/21
- Re: a coreutils release is imminent, Paul Eggert, 2007/03/21