Subject: bin/20637: update build of crunched binaries causes build failure
To: None <gnats-bugs@gnats.netbsd.org>
From: None <he@netbsd.org>
List: netbsd-bugs
Date: 03/09/2003 17:33:12
>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: