[PATCH] [SUMMARY] (Re: Build under FreeBSD-STABLE broken?)

qhwt at myrealbox.com qhwt at myrealbox.com
Wed Aug 20 19:38:56 PDT 2003

On Wed, Aug 20, 2003 at 10:07:03AM -0700, Matthew Dillon wrote:
> :
> :The first patch(bsd.kmod.mk.diff) modifies bsd.kmod.mk so that it can
> :set SYSDIR properly when .CURDIR is one- or five-level deeper than
> :the top of sys directory, which include:
> :  sys/crypto
> :  sys/dev/disk/aic7xxx/ahc/ahc_eisa
>     Ok, I'll commit this one.


> :The second patch(svr4-Makefile.diff) fixes sys/emulation/svr4/Makefile
> :by replacing .CURDIR with .OBJDIR, so that it looks at the files under
> :/usr/obj rather than in the source tree. You never notice if you have
> :write access to the source tree.
>     I don't think this is correct.  Nobody should be regenerating the
>     system calls in the normal course of business.  The way it works is
>     that when a developer changes a system call the developer regenerates
>     them and then commits the regenerated files.

Oh, I didn't think of that.

>     Is something running these targets during a normal build that
>     shouldn't be?

Well... ah, 'sysent' is the first target of sys/emulation/svr4/Makefile,
so running make in sys/emulation/svr4 always tries to regenerate sysent
target. At least other Makefiles under sys/emulation have other rules or
dummy 'all' target. I'm running buildworld/buildkernel again with
following patch.

Index: sys/emulation/svr4/Makefile
RCS file: /home/source/dragonfly/cvs/src/sys/emulation/svr4/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- sys/emulation/svr4/Makefile	15 Aug 2003 06:32:56 -0000	1.5
+++ sys/emulation/svr4/Makefile	21 Aug 2003 02:11:28 -0000
@@ -5,6 +5,9 @@
 MAINTAINER=	newton at xxxxxxxxxxx
+	@echo "make sysent only (generates gsvr4_sysent.c svr4_syscall.h svr4_proto.h svr4_union.h)"
 # This regenerates the system calls
 sysent:	${.CURDIR}/svr4_sysent.c


More information about the Bugs mailing list