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