Date: Tue, 21 Jun 2011 18:20:03 -0400 (EDT) From: Benjamin Kaduk <kaduk@MIT.EDU> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-hackers@FreeBSD.org Subject: Re: porting third-party build system to bsd.kmod.mk Message-ID: <alpine.GSO.1.10.1106211103470.6818@multics.mit.edu> In-Reply-To: <8854CF36-7B6D-4918-ADF8-6A16CCB2F307@bsdimp.com> References: <alpine.GSO.1.10.1105210148300.6818@multics.mit.edu> <8854CF36-7B6D-4918-ADF8-6A16CCB2F307@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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<Makefile.txt><build.log>_______________________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.1.10.1106211103470.6818>