>Number:         22324
>Category:       port-powerpc
>Synopsis:       All powerpc-using ports currently fail to compile kernels
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-powerpc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 31 14:13:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Havard Eidnes
>Release:        NetBSD 1.6U Jul 31 2003
>Organization:
	Unorganized, Inc.
>Environment:
System: NetBSD stegg.urc.uninett.no 1.6U NetBSD 1.6U (STEGG.MP) #0: Mon Jul 21 01:03:25 CEST 2003  he@stegg.urc.uninett.no:/usr/obj/sys/arch/i386/compile.i386/STEGG.MP i386
Architecture: i386
Machine: i386
>Description:
	While trying to cross-compile ports to detect and iron out
	build bugs, I've found that after the recent changes to the
	make rules, none of the powerpc-using ports will be able to
	compile kernels.  The symptoms are either:

	a) on an UPDATE build, while building libkern as an object
	   file, duplicate symbols in bzero.o and memset.o.
	b) on a clean build, the "depends" stage fails because assym.h
	   is not generated before libkern's arch-dependent bzero.S is
	   being processed.

	sys/lib/libkern/arch/powerpc/bzero.S is however currently
	commented out in that directory's Makefile.inc, indicating
	that bzero.c should be used until the bugs in bzero.S can be
	ironed out.

	However, make's new depend rules when trying to find the
	sources for a .d file will first look for .s, then .S, and
	*then* for .c, irrespective of whether the file is mentioned
	as a source file or not.  Therefore, the supposed-to-be-
	inactive bzero.S is being automatically picked up by the new
	make rules.  Some make debug output reveals this:

SuffFindDeps (strrchr.d)
        trying strrchr.s...Searching for strrchr.s...failed.
not there
        trying strrchr.S...Searching for strrchr.S.../usr/users/he/src/sys/lib/libkern/arch/powerpc...failed.
not there
        trying strrchr.c...got it
strrchr.d:@ = strrchr.d
strrchr.d:* = strrchr
        applying .c -> .d to "strrchr.d"
...
Searching for bzero.S...failed.
bzero.S:@ = bzero.S
SuffFindDeps (bzero.S)
bzero.S:@ = bzero.S
bzero.S:* = bzero
Searching for bzero.S.../usr/users/he/src/sys/lib/libkern/arch/powerpc...here...returning /usr/users/he/src/sys/lib/libkern/arch/powerpc/bzero.S
bzero.S:@ = /usr/users/he/src/sys/lib/libkern/arch/powerpc/bzero.S
bzero.S:* = bzero

	The failure of "make depend" appears to be caused by multiple
	definitions of the "depend" target.  In make's debug output
	(which I think leaves quite a bit to be desired, BTW), I find
	both:

depend          : .NOTMAIN .PHONY realdepend subdir-depend 
realdepend      : .NOTMAIN .PHONY beforedepend .depend afterdepend 

	which would process the main directory's .depend (and
	therefore create assym.h) before descending into the
	subdirectories.  However, I also find

depend:> = dependkernlib
depend:? = dependkernlib
depend:> = dependkernlib dependcompatlib
depend:? = dependkernlib dependcompatlib
depend:> = dependkernlib dependcompatlib .depend
depend:? = dependkernlib dependcompatlib .depend

	and it appears that it's the latter which is actually being
	used(?!)

	This "order of make depend stages" problem is only relevant
	for powerpc and hppa, since those are the only two
	architectures which use assym.h from libkern's arch-dependent
	subdir.


>How-To-Repeat:
	Try to build a macppc or prep kernel from -current sources as
	of today; watch it fail.

>Fix:
	A workaround could be to remove or rename

	sys/lib/libkern/arch/powerpc/bzero.S

	so that the file would not be picked up by make's automatic
	suffix and PATH search rules.  However, that's probably not
	the appropriate fix.
>Release-Note:
>Audit-Trail:
>Unformatted: