>Number:         20637
>Category:       bin
>Synopsis:       update build of crunched binaries causes build failure
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 09 08:34:00 PST 2003
>Closed-Date:
>Last-Modified:
>Originator:     Havard Eidnes
>Release:        NetBSD 1.6P 9 Mar 2003
>Organization:
	Unorganized, Inc.
>Environment:
Build host: NetBSD stegg.urc.uninett.no 1.6N NetBSD 1.6N (STEGG.MP) #5: Fri Feb  7 07:41:54 CET 2003     he@stegg.urc.uninett.no:/usr/obj/sys/arch/i386/compile/STEGG.MP i386
System: cross-build of mvme68k
Architecture: mvme68k
Machine: m68k
>Description:
	Trying to do an "update" build of crunched binaries appears to
	cause reproducible build errors.

	This is typically observed in miniroot or rescue builds, as on
	mvme68k in the miniroot build:

all ===> miniroot
rm -f instbin.conf instbin.conf.tmp
ARCHDIR=/usr/users/he/src/distrib/miniroot/../mvme68k/miniroot  DISTRIBREV=16P  DISTRIBVER=1.6P  KERNOBJDIR=/usr/users/he/src/sys/arch/mvme68k/compile/obj.mvme68k NETBSDSRCDIR=/usr/users/he/src  CRUNCHBIN=instbin  CURDIR=/usr/users/he/src/distrib/miniroot  DESTDIR=/usr/dest/mvme68k  DISTRIBDIR=/usr/users/he/src/distrib  MACHINE=mvme68k  MACHINE_ARCH=m68k  OBJDIR=/usr/users/he/src/distrib/miniroot/obj.mvme68k TARGETDIR=/usr/users/he/src/distrib/miniroot/obj.mvme68k/work awk -f /usr/users/he/src/distrib/common/parselist.awk -v mode=crunch /usr/users/he/src/distrib/miniroot/list /usr/users/he/src/distrib/miniroot/../mvme68k/miniroot/list /usr/users/he/src/distrib/common/list.sysinst > instbin.conf.tmp  && mv instbin.conf.tmp instbin.conf
...
if [ \! -d progress ]; then mkdir progress; fi; cd progress;  printf ".PATH: /usr/users/he/src/usr.bin/progress\n.CURDIR:= /usr/users/he/src/usr.bin/progress\n.include \"\${.CURDIR}/Makefile\"\n"  | /usr/tools/bin/nbmake CRUNCHEDPROG=1 DBG="-O2" -f- depend progress.o progressbar.o
`progress.o' is up to date.
`progressbar.o' is up to date.
/usr/tools/bin/m68k--netbsdelf-gcc -O2   -Werror  -nostdinc -isystem /usr/dest/mvme68k/usr/include  -c instbin.c
/usr/tools/bin/m68k--netbsdelf-gcc -O2   -Werror  -nostdinc -isystem /usr/dest/mvme68k/usr/include  -c expr/expr.c
/usr/tools/bin/m68k--netbsdelf-gcc -O2   -Werror  -nostdinc -isystem /usr/dest/mvme68k/usr/include  -c sh/arith.c
/usr/tools/bin/m68k--netbsdelf-gcc -O2   -Werror  -nostdinc -isystem /usr/dest/mvme68k/usr/include  -c sh/arith_lex.c
/usr/users/he/src/bin/sh/arith_lex.l:50: arith.h: No such file or directory
*** [sh/arith_lex.o] Error code 1
1 error

nbmake: stopped in /usr/users/he/src/distrib/miniroot/obj.mvme68k
*** Error code 2

	Inspection after the build failure reveals that the most
	recently built objects from the bourne shell have landed in
	the main object directory, not in the sh/ subdirectory where
	they belong:

stegg# pushd distrib/miniroot/obj.mvme68k
stegg# ls -ltr
...
drwxr-xr-x   2 root  users      512 Mar  9 17:09 progress/
-rw-r--r--   1 root  users     6636 Mar  9 17:09 instbin.o
-rw-r--r--   1 root  users     9096 Mar  9 17:09 expr.o
-rw-r--r--   1 root  users     8076 Mar  9 17:09 arith.o
stegg#

	arith_lex.c depends on the arith.h header which is sitting
	nicely in the sh/ subdirectory, but isn't in the main
	directory of course.

	I have been trying to find read debug output from make, but
	apparently it just says "target is out of date", but does not
	tell anything about which dependency is triggering the OOD
	condition, nor the timestamp of the dependency.  Adding a
	time-stamp prinout to make reveals:

Examining sh/arith_lex.o...modified 14:18:33 Mar 07, 2003...modified before source... (source: 17:20:30 Mar 09, 2003)out-of-date

	But... None of the source files in bin/sh/, at least, has that
	timestamp, though the sh/.depend file has that date, but none
	of the files in that file have that timestamp, and arith_lex.c
	is:

-rw-r--r--  1 root  users   42405 Mar  7 14:18 arith_lex.c

	in obj.mvme68k/sh/.

>How-To-Repeat:
	Do an update build of either rescue or miniroot.
>Fix:
	Sorry, have not been able to figure this one out yet.
>Release-Note:
>Audit-Trail:
>Unformatted: