From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 21 22:20:08 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 656B2106564A for ; Tue, 21 Jun 2011 22:20:08 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by mx1.freebsd.org (Postfix) with ESMTP id 0E64B8FC13 for ; Tue, 21 Jun 2011 22:20:07 +0000 (UTC) X-AuditID: 12074424-b7bc6ae000005a77-e0-4e0119170e28 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id A7.D0.23159.719110E4; Tue, 21 Jun 2011 18:20:07 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p5LMK5lx022928; Tue, 21 Jun 2011 18:20:05 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p5LMK4pO004131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jun 2011 18:20:05 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p5LMK3pY016537; Tue, 21 Jun 2011 18:20:03 -0400 (EDT) Date: Tue, 21 Jun 2011 18:20:03 -0400 (EDT) From: Benjamin Kaduk To: Warner Losh In-Reply-To: <8854CF36-7B6D-4918-ADF8-6A16CCB2F307@bsdimp.com> Message-ID: References: <8854CF36-7B6D-4918-ADF8-6A16CCB2F307@bsdimp.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixCmqrCsuyehn8Oocr8X2zf8YLZ5uXc7o wOTxYfdXVo8Zn+azBDBFcdmkpOZklqUW6dslcGWcW3ODqeC3esWMfXvZGhjPKXQxcnJICJhI vD98hAnCFpO4cG89G4gtJLCPUWLd+pguRi4gewOjxLQ3zcwQiQNMEgumOkIkGhglln/oButm EdCWeLzhJZjNJqAiMfPNRrBJIgIKEquO3GUBsZkF5CXOnrsJZgsL2Ej8/vcQrIZTwE7iw44L rCA2r4CDRM9WCFtIoEji3v6NYDNFBXQkVu+fwgJRIyhxcuYTqJmWEv/W/mKdwCg4C0lqFpLU AkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbrmermZJXqpKaWbGEGByu6isoOx+ZDSIUYBDkYl Ht6fOxj8hFgTy4orcw8xSnIwKYnyckow+gnxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4U3eClTO m5JYWZValA+TkuZgURLnLfX+7yskkJ5YkpqdmlqQWgSTleHgUJLg7QQZKliUmp5akZaZU4KQ ZuLgBBnOAzScA6SGt7ggMbc4Mx0if4rRmGP7gpeHGDlOzX1ziFGIJS8/L1VKnNdXDKhUAKQ0 ozQPbhos2bxiFAd6TpjXC2QgDzBRwc17BbSKCWjV/1f/fIFWlSQipKQaGBmdpX5uDZ7Fdbbh X0LKl/lvfXh5dx7RUC18uegp08fUv/KfDfdOtH3dfkZK78HE86+SQ+VtXu/amiuqcTY69j1b wUluT/a28L0TO/kX3nQz+10k1vDyuJgR9yzWnU4XNguYqayfu8w0vLhjdl2NUjvD8/StG47v +D21/V7By2jhtaEZ79oV5iixFGckGmoxFxUnAgB3aXpxEQMAAA== Cc: freebsd-hackers@FreeBSD.org Subject: Re: porting third-party build system to bsd.kmod.mk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 22:20:08 -0000 Picking up this problem after a long hiatus... On Sun, 22 May 2011, Warner Losh wrote: > The usual reason that vnode_if.h doesn't build for me when I'm doing > in-tree hacking is because make depend hasn't run to generate it yet. > Or more precisely, the arc in the dependency graph from osi_crypto.c to > vnode_if.h. I didn't see that as part of the log, so you might try this > first (and make setup dependent on depend somehow, as long as it is > idempotent. Ah, thanks for that pointer, having setup depend on 'depend' does help get SRCS=vnode_if.h to actually work. However, that does not solve all of my problems; the "too many arguments to gcc with -o and -c" problem remains. It stems from the way upstream's Makefile is structured to build the object files: afs_analyze.o: $(TOP_SRC_AFS)/afs_analyze.c $(CRULE_OPT) CRULE_OPT= $(CC) $(COMMON_INCLUDE) $(KERN_DBG) $(KERN_OPTMZ) $(CFLAGS) $(CFLAGS-$@) -o $@ -c $? $? picks up ${_ILINKS} and apparently ${SRCS} as having been out-of-date when the run was started, which produes the error. Since I don't think I can convince make to not do that, I'm mostly resigned to redefining CRULE_OPT to use ${?:M*.c}, which lets things proceed fairly nicely, and build a bunch of objs. However, the build eventually dies with: make: don't know how to make .o. Stop The following 'make -d A' output proves enlightening: Global:SRCS = vnode_if.h [...] Global:OBJS = ${AFSAOBJS} ${AFSNONFSOBJS} ${SRCS:N*.h:R:S/$/.o/g} Global:PROG = ${KMOD}.ko Global:FULLPROG = ${PROG} lhs = "no", rhs = "yes", op = == Global:EXPORT_SYMS = NO lhs = "NO", rhs = "YES", op = != Global:CLEANFILES = export_syms lhs = "no", rhs = "yes", op = == Applying :N to "vnode_if.h" Result is "" Applying :R to "" Result is "" Applying :S to "" Result is ".o" [...] make: don't know how to make .o. Stop It looks like I may be able to work around by putting something else in SRCS instead of OBJS, but it is still rather interesting behavior, and might be considered a bug under some sets of assumptions. Any insight into whether it is/is not possible to have $? be just the C source, or about the issue where the empty string becomes ".o" would be appreciated. Or do I always want to redefine CRULE_OPT to something set by the system makefiles? (There is also a CRULE_NOOPT which is similar.) > > But many of the things that are being setup with the setup target > shouldn't be necessary. depend does that based on the setting of > SYSDIR. and the @ symlink should be enough to make the ufs and other > symlinks unnecessary. > At least some of them will require code changes, but I suppose that I can do that with a flag day. Thanks, Ben > On May 21, 2011, at 12:14 AM, Benjamin Kaduk wrote: > >> After getting a few pointers from jhb at BSDCan on what a >> bsd.kmod.mk-using Makefile should look like, I have been trying my hand >> at porting the OpenAFS kernel module build system to use it. (The main >> thing this gets us is not having to manually track version- and >> architecture-dependent CFLAGS and the like.) However, the path is not >> exactly smooth. >> >> A lot of the difficulty is in getting an autogenerated vnode_if.h while using a list of files to include in the module(from the common OpenAFS code) that's given as a list of object files. If there's already a vnode_if.h sitting around, I can just use OBJS and things progress quite nicely; however, if I have to get back to SRCS for the use of sys/conf/kmod.mk's vnode_if.h logic, I get this sort of build failure (full log attached) with the attached Makefile: >> gcc -I. -I.. -I../nfs [more includes and defines] -I/usr/devel/openafs/git/openafs/include/afs -I@/sys -Imachine -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wno-redundant-decls -Wsystem-headers -Werror -Wno-pointer-sign -o osi_crypto.o -c /usr/devel/openafs/git/openafs/src/afs/FBSD/osi_crypto.c /usr/devel/openafs/git/openafs/src/libafs/MODLOAD/../../afs/FBSD/osi_crypto.c vnode_if.h >> gcc: cannot specify -o with -c or -S with multiple files >> >> That last bit, "-o osi_crypto.o -c /path/to/osi_crypto.c /path/to/osi_crypto.c vnode_if.h" is quite troublesome. Any thoughts on what is causing those extra files to be listed would be greatly appreciated. (Comments on other issues in the Makefile are welcome, too -- it's still in pretty rough shape.) >> >> I should note that though Makefile.common does define a osi_crypto.o target, "make -d A" reports: >> using existing source /usr/devel/openafs/git/openafs/src/afs/FBSD/osi_crypto.c >> applying .c -> .o to "osi_crypto.o" >> >> >> Thanks, >> >> Ben Kaduk_______________________________________________