Spurious make check failures due to automounter interaction
Rainer Orth
ro@TechFak.Uni-Bielefeld.DE
Mon Dec 21 13:30:00 GMT 1998
When I run make check against egcs built from current CVS sources on
Digital UNIX V4.0B, I get some spurious failures.
>From gcc/testsuite/gcc.log:
Executing on host: /tmp/egcs/gcc/xgcc -B/tmp/egcs/gcc/ /amnt/pharao/volumes/c3t3d0s5/egcs/src/egcs/egcs/egcs/gcc/testsuite/gcc.c-torture/compile/920729-1.c -w -O2 -c -o /tmp/egcs/gcc/testsuite/920729-1.o
spawn /tmp/egcs/gcc/xgcc -B/tmp/egcs/gcc/ /amnt/pharao/volumes/c3t3d0s5/egcs/src/egcs/egcs/egcs/gcc/testsuite/gcc.c-torture/compile/920729-1.c -w -O2 -c -o /tmp/egcs/gcc/testsuite/920729-1.o
xgcc: /amnt/pharao/volumes/c3t3d0s5/egcs/src/egcs/egcs/egcs/gcc/testsuite/gcc.c-torture/compile/920729-1.c: No such file or directory
xgcc: No input files
compiler exited with status 1
output is:
xgcc: /amnt/pharao/volumes/c3t3d0s5/egcs/src/egcs/egcs/egcs/gcc/testsuite/gcc.c-torture/compile/920729-1.c: No such file or directory
xgcc: No input files
FAIL: gcc.c-torture/compile/920729-1.c, -O2
while xgcc had no problem at all finding all previous source files. The
problem is that the check-gcc target in gcc/Makefile (and some others, too)
use
srcdir=`cd ${srcdir}; pwd` ; export srcdir ; \
In the presence of (non-autofs) automounters, the resulting pathname is
likely to become invalid once amd unmounts the underlying filesystem, which
it may do, since no accesses via the amd-supported path (/vol/egcs instead
of /amnt/...) have taken place for some time.
Why is this cd/pwd construct used all, instead of just
export ${srcdir}
Isn't ${srcdir} guaranteed to be an absolute pathname anyway?
Rainer
More information about the Gcc-bugs
mailing list