Re: make check problems with coreutils 7.2 and earlier

[Jim Meyering]

Tim Mooney wrote:
> [I'm not subscribed to bug-coretuils, please Cc: me on any relevant
> replies]
> I'm building coreutils on x86_64-sun-solaris2.10, with the Sun Studio 12
> and/or Express compilers.  I'm building in 64 bit mode.  Everything builds
> just fine, but before I finish packaging the software I always run "make
> check", to see what problems might turn up and how make check from one
> version of the software differs from make check in previous versions.
>
> I haven't been able to successfully use "make check" with coreutils in
> a while.  The problem appears to be that several of the tests are
> performed without the correct PATH, because instead of getting the
> version of the program that was compiled in src/, it's getting the version
> of a particular command that's part of the OS.  This is especially
> problematic when testing "yes".  The Solaris version of yes doesn't
> support any of the command line arguments that the tests try, so the
> tests essentially hang while Solaris' yes loops continuously outputting
> things like "--help".

Thanks for the report.
The tests are designed always to set PATH to make
your shell use the just-built tools.

If that's not happening for you, either the tool (yes) wasn't built
or your shell is not honoring the PATH settings in the TESTS_ENVIRONMENT
variable, as set in tests/check.mk.  I suspect the latter.
It'd be useful to know which shell configure chose for you.
configure does try to find a sufficiently functional shell,
but perhaps your system has managed to trick it.

Please send (to this same list) the output of running your
configure command, and the output from running "make check".

> I'm configuring the software like this
>
>           ./configure --prefix=/local/gnu --exec-prefix=/local/gnu \
>         --build "x86_64-sun-solaris2.10" \
>         --sysconfdir=/etc/local/gnu --libdir=/local/gnu/lib/64 \
>         --mandir=/local/gnu/share/man --infodir=/local/gnu/share/info \
>         --localstatedir=/var/local/gnu \
>         --disable-nls
>
> and then doing
>
> gmake
> gmake check VERBOSE=yes
>
> (gmake is GNU make 3.81).
>
> I've checked the mailing list archives and I don't see any recent reports
> of this issue, though, and I would think others would have run into the
> same thing.  Is this a known issue, or should I investigate further?

We've seen similar reports, but not recently.  Previous reports have been
on rather old systems, with an inadequate /bin/sh and where configure
failed to find a better shell.

> Also, the README that comes with coreutils has a section on "Reporting
> bugs" and what you should do when reporting them, but it doesn't actually

That paragraph requests that you send in more details ;-)

    IMPORTANT: if you take the time to report a test failure,
    please be sure to include the output of running `make check'
    in verbose mode for each failing test.  For example,
    if the test that fails is tests/misc/df, then you would
    run this command:

      (cd tests && make check TESTS=misc/df VERBOSE=yes) >> log 2>&1

    For some tests, you can get even more detail by adding DEBUG=yes.
    Then include the contents of the file `log' in your bug report.


> include the address to report them to.  People familiar with other GNU
> packages can probably guess what the address is, but it would still be
> good to actually include the address in the README.

It's listed in the paragraph just below that one.
But I've added another mention with the patch below:

>From 82169bbf6efeb9d60fc457cfd995c3ff0497365b Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Sat, 18 Apr 2009 09:17:04 +0200
Subject: [PATCH] doc: update README

* README: (Reporting bugs): List the bug-reporting address here, too,
not just in the following more test-oriented paragraph.
Reported by Tim Mooney.
All changes are no longer listed in version-controlled ChangeLog
files, so note that contributions are attributed in the commit logs.
Mention bootstrap.conf, now that it's the authoritative source of
minimal prerequisite program/version# pairs.
---
 README |   14 ++++++--------
 1 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/README b/README
index e7499e7..08e0bab 100644
--- a/README
+++ b/README
@@ -41,7 +41,7 @@ Special thanks to Paul Eggert, Brian Matthews, Bruce Evans, 
Karl Berry,
 Kaveh Ghazi, and François Pinard for help with debugging and porting
 these programs.  Many thanks to all of the people who have taken the
 time to submit problem reports and fixes.  All contributed changes are
-attributed in the ChangeLog files.
+attributed in the commit logs.

 And thanks to the following people who have provided accounts for
 portability testing on many different types of systems: Bob Proulx,
@@ -173,6 +173,10 @@ run this command:
 For some tests, you can get even more detail by adding DEBUG=yes.
 Then include the contents of the file `log' in your bug report.

+Send bug reports, questions, comments, etc. to address@hidden
+If you would like to suggest a patch, see the files README-hacking
+and HACKING for tips.
+
 ***************************************

 There are many tests, but nowhere near as many as we need.
@@ -209,13 +213,7 @@ subtle bugs.
 WARNING:  If you modify files like configure.in, m4/*.m4, aclocal.m4,
 or any Makefile.am, then don't be surprised if what gets regenerated no
 longer works.  To make things work, you'll have to be using appropriate
-versions of automake and autoconf.  As for what versions are `appropriate',
-use the versions of
-
-  * autoconf specified via AC_PREREQ in m4/jm-macros.m4
-  * automake specified via AM_INIT_AUTOMAKE in configure.ac
-
-Usually it's fine to use versions that are newer than those specified.
+versions of the tools listed in bootstrap.conf's buildreq string.

 All of these programs except `test' recognize the `--version' option.
 When reporting bugs, please include in the subject line both the package
--
1.6.3.rc0.200.g4086