Subject: bin/7374: make apparently checks dependencies from wrong dir
To: None <gnats-bugs@gnats.netbsd.org>
From: None <arnej@math.ntnu.no>
List: netbsd-bugs
Date: 04/13/1999 22:16:48
>Number:         7374
>Category:       bin
>Synopsis:       make apparently checks dependencies from wrong dir
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 13 15:35:00 1999
>Last-Modified:
>Originator:     Arne Juul
>Organization:
	Norwegian University of Technology and Science
>Release:        NetBSD-current du jour (Apr 13 1999)
>Environment:
	
System: NetBSD fimfpc30.math.ntnu.no 1.4_ALPHA NetBSD 1.4_ALPHA (GENERIC) #1: Tue Apr 13 17:41:06 CEST 1999 root@fimfpc30.math.ntnu.no:/usr/src/sys/arch/i386/compile/GENERIC i386


>Description:
	I got strange messages on my screens when I built kernels:
Apr 13 19:01:52 fimfpc30 amd[172]: Unknown host: radix.h
Apr 13 19:13:48 fimfpc30 amd[172]: Unknown host: radix.h
Apr 13 19:25:25 fimfpc30 amd[172]: Unknown host: radix.h
Apr 13 19:33:45 fimfpc30 amd[172]: Unknown host: radix.h
	I tracked this to the fact that I have an AMD "hosts" map
	mounted on the /net directory, so any access to files in
	that directory will be interpreted by AMD as host names.
	But why does the kernel make access /net/radix.h at all,
	it should be "self-contained" in /usr/src/sys, and why
	only that single file?

	I found that this happens because of the way the compat
	library is built in a subdir and how the dependence file
	looks like.  First: I get the following in the autogenerated
	/usr/src/sys/arch/i386/compile/GENERIC/lib/compat/.depend:
 ../../../../../../sys/mount.h ../../../../../../net/radix.h \
 ../../../../../../sys/mount.h ../../../../../../net/radix.h \
 ../../../../../../net/radix.h ../../../../../../sys/syscallargs.h
 ../../opt_multiprocessor.h ../../../../../../net/radix.h \
 ../../../../../../sys/mount.h ../../../../../../net/radix.h \
 ../../opt_multiprocessor.h ../../../../../../net/radix.h \
 ../../../../../../net/radix.h ../../../../../../sys/syscallargs.h
 ../../../../../../sys/mount.h ../../../../../../net/radix.h \
 ../../../../../../net/radix.h ../../../../../../sys/socket.h \
 ../../../../../../net/radix.h ../../../../../../sys/socket.h \
 ../../../../../../net/radix.h ../../../../../../sys/socket.h \
 ../../opt_multiprocessor.h ../../../../../../net/radix.h \
 ../../../../../../net/radix.h ../../../../../../sys/socket.h \
 ../../opt_multiprocessor.h ../../../../../../net/radix.h \
	as you can see, only net/radix.h is used by the compat
	library files, and (even more interesting) it is accessed
	by the relative name, with lots of "../" first.  The number
	is correct for access from the build directory
	/usr/src/sys/arch/i386/compile/GENERIC/lib/compat/.depend
	and *only* from there.

	BUT: when the main make (in /sys/arch/i386/compile/GENERIC)
	is building the kernel compat library, it calls COMPATMAKE
	(as defined in /usr/src/sys/compat/common/Makefile.inc) which
	does effectively a "cd /usr/src/sys/compat/common" first,
	reads the Makefile there, slurps in the .depend file above,
	chdir()s to the correct directory, but then carefully prepends
	the "source" directory (/usr/src/sys/compat/common) first to
	all the stat() calls.

	It seems this has something to do with how make internally
	handles MAKEOBJDIR versus the current directory, especially
	with regards to relative pathnames.  I don't have any idea
	of how serious a problem this really is; it's really obscure
	I think.  Also, maybe it's necessary for make to stat some
	dependencies from the source dir instead of the obj dir.
	All in all, this is *way* over my head...

>How-To-Repeat:

This is for NetBSD/i386, other archs can probably trigger this
similarly:
	cd /sys/arch/i386/conf ; config GENERIC;
	cd /sys/arch/i386/compile/GENERIC; make depend;
	ktrace -i -t cn make;
	kdump | grep -1 'compat.*radix.h'

Alternatatively, I can cobble up something similar that doesn't
involve the full kernel build :-)

>Fix:
	unknown.
>Audit-Trail:
>Unformatted: