bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

make check problems with coreutils 7.2 and earlier


From: Tim Mooney
Subject: make check problems with coreutils 7.2 and earlier
Date: Fri, 17 Apr 2009 13:37:04 -0500 (CDT)


[I'm not subscribed to bug-coretuils, please Cc: me on any relevant
replies]

All-

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".

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?

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
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.

Thanks,

Tim
--
Tim Mooney                                             address@hidden
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164




reply via email to

[Prev in Thread] Current Thread [Next in Thread]