[Top][All Lists]

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

Re: "make check" failure [with "." at beginning of PATH]

From: Jim Meyering
Subject: Re: "make check" failure [with "." at beginning of PATH]
Date: Sat, 09 Feb 2008 09:01:10 +0100

Bruno Haible <address@hidden> wrote:
> Building coreutils-6.10 on a Linux/x86 machine fails like this for me:
> $ ./configure --prefix=/packages/gnu CPPFLAGS=-Wall
> $ make 2>&1 | tee log1
> $ make check 2>&1 | tee log2
> ...

Thanks for the report.
I suspect there is something unusual about this system or your environment,
since this is the first such failure report I've seen for 6.10.

> Making check in misc
> make[2]: Entering directory `/build/coreutils-6.10/tests/misc'
> make  check-TESTS
> make[3]: Entering directory `/build/coreutils-6.10/tests/misc'
> make[4]: Entering directory `/build/coreutils-6.10/tests/misc'
> /packages/gnu/bin/mkdir: cannot create directory `': No such file or directory
> /packages/gnu/bin/mkdir -p "$(dirname help-version.log)" || exit; \
> What is the fifth part of this command meant to be? "$(dirname ...)" ??
> It comes from build-aux/check.mk. It's certainly not meant as a GNU make
> expression, since you don't normally assume GNU make. So it's a shell
> expression.


> There are two problems:
> 1) Backquotes should be used instead of bash-specific syntax.

Since November, tests and infrastructure can use POSIX-shell syntax
like $() on most systems.  See the posix-shell gnulib module and
this change by Paul Eggert:


> 2) 'dirname' refers to the program in PATH. My $PATH starts with ".". "." is

Ah ha!  *That* is the problem.
Don't put "." in your PATH at all, and especially not at the front.

>    the tests/misc directory. tests/misc/dirname is a test which prints nothing
>    to stdout, hence `./dirname help-version.log` is empty.

All test scripts are run in an environment in which
PATH never starts with ".".  There, PATH starts with $(abs_top_builddir)/src
which contains the just built dirname executable.
However, the build-related snippet you quoted is run outside that
environment (to set it up, in fact), and expects a sane PATH.

If you see an easy, clean fix, then great.  Otherwise, I wouldn't
worry about it: the upcoming release of automake will provide similar
capabilities, and then I'll be able to remove most of build-aux/check.mk.

reply via email to

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