How to build kernel module spread on subdirectories?

Nikola Knežević laladelausanne at gmail.com
Sat Nov 29 03:40:53 PST 2008


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

  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kmod.mk.patch
Type: application/octet-stream
Size: 575 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081129/b1f5f100/kmod.mk.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sys.mk.patch
Type: application/octet-stream
Size: 353 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20081129/b1f5f100/sys.mk.obj


More information about the freebsd-hackers mailing list