On 25 Nov 2008, at 15:20 , Nikola Knežević wrote:
I tried to move from OBJS into SRCS (main BSDmakefile now has: SRCS+= $(ELEMENT_SRCS)), by using something like:# subdir0 ELEMENT_SRCS__x =\ subdir1/file0.cc \ subdir1/file1.cc...But this fails during the linking phase, because the linker is called with subdir1/file0.o, instead of just file0.o.To make something clear, I didn't just rewrite the GNUmakefile to BSDmakefile, I also followed some of the logic used to build kernel modules. I'm including bsd.kmod.ko, list sources in SRCS, don't have any explicit rule to build .o out of .cc/.c. There is no all: target, as well.
Hi,since there were no replies, I went into the various .mk's, and I found some inconsistencies when building modules. If you have a file in a different directory, below the directory where you BSDmakefile is, objects won't be linked nor cleaned properly.
Default .c rule builds the object file in the .OBJDIR. But, when we have files with absolute paths in SRCS, they get transfered verbatim to OBJS, transforming only the suffix .c -> .o. When we want to build the module, final rule is (at least on amd64):
${FULLPROG}: ${OBJS}
${LD} ... -o ${.TARGET} ${OBJS}
which is wrong, because linker gets the absolute paths to .o files,
which do not exist at that place. It would be better to use ${OBJS:T}
So I propose the attached patch kmod.ko to circumvent this problem.While I'm at it, I've attached another patch for /usr/share/mk/sys.mk, which resolves a problem when one uses g++ during a building of a kernel module.
Cheers, Nikola
kmod.mk.patch
Description: Binary data
sys.mk.patch
Description: Binary data
_______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
