Date: Sat, 29 Nov 2008 12:40:47 +0100 From: =?UTF-8?Q?Nikola_Kne=C5=BEevi=C4=87?= <laladelausanne@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: How to build kernel module spread on subdirectories? Message-ID: <2A1A4C21-8A2D-4151-BCA0-5FAE1D3BBE86@gmail.com> In-Reply-To: <711D7381-D852-4B6B-991A-84BA6DEFB679@gmail.com> References: <711D7381-D852-4B6B-991A-84BA6DEFB679@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail-17-543544471
Content-Type: text/plain;
charset=UTF-8;
format=flowed;
delsp=yes
Content-Transfer-Encoding: quoted-printable
On 25 Nov 2008, at 15:20 , Nikola Kne=C5=BEevi=C4=87 wrote:
> I tried to move from OBJS into SRCS (main BSDmakefile now has: SRCS+=3D=20=
> $(ELEMENT_SRCS)), by using something like:
> # subdir0
> ELEMENT_SRCS__x =3D\
> subdir1/file0.cc \
> subdir1/file1.cc
>
> ...
>
> But this fails during the linking phase, because the linker is =20
> called with subdir1/file0.o, instead of just file0.o.
>
> To make something clear, I didn't just rewrite the GNUmakefile to =20
> BSDmakefile, I also followed some of the logic used to build kernel =20=
> modules. I'm including bsd.kmod.ko, list sources in SRCS, don't have =20=
> any explicit rule to build .o out of .cc/.c. There is no all: =20
> target, as well.
Hi,
since there were no replies, I went into the various .mk's, and I =20
found some inconsistencies when building modules. If you have a file =20
in a different directory, below the directory where you BSDmakefile =20
is, objects won't be linked nor cleaned properly.
Default .c rule builds the object file in the .OBJDIR. But, when we =20
have files with absolute paths in SRCS, they get transfered verbatim =20
to OBJS, transforming only the suffix .c -> .o. When we want to build =20=
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, =20
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, =20=
which resolves a problem when one uses g++ during a building of a =20
kernel module.
Cheers,
Nikola
=20=
--Apple-Mail-17-543544471
Content-Disposition: attachment;
filename=kmod.mk.patch
Content-Type: application/octet-stream; x-unix-mode=0644; name="kmod.mk.patch"
Content-Transfer-Encoding: 7bit
--- kmod.mk.orig 2008-11-29 12:28:54.000000000 +0100
+++ kmod.mk 2008-11-29 12:27:26.000000000 +0100
@@ -193,7 +193,7 @@
.else
${FULLPROG}: ${OBJS}
.endif
- ${LD} ${LDFLAGS} -r -d -o ${.TARGET} ${OBJS}
+ ${LD} ${LDFLAGS} -r -d -o ${.TARGET} ${OBJS:T}
.if defined(EXPORT_SYMS)
.if ${EXPORT_SYMS} != YES
.if ${EXPORT_SYMS} == NO
@@ -251,7 +251,7 @@
${ECHO} ${.TARGET} "->" $$path ; \
ln -sf $$path ${.TARGET}
-CLEANFILES+= ${PROG} ${KMOD}.kld ${OBJS}
+CLEANFILES+= ${PROG} ${KMOD}.kld ${OBJS:T}
.if defined(DEBUG_FLAGS)
CLEANFILES+= ${FULLPROG} ${PROG}.symbols
--Apple-Mail-17-543544471
Content-Disposition: attachment;
filename=sys.mk.patch
Content-Type: application/octet-stream; x-unix-mode=0644; name="sys.mk.patch"
Content-Transfer-Encoding: 7bit
--- sys.mk~ 2008-09-05 16:30:26.000000000 +0200
+++ sys.mk 2008-09-16 14:59:40.000000000 +0200
@@ -62,7 +62,7 @@
.endif
CXX ?= c++
-CXXFLAGS ?= ${CFLAGS:N-std=*:N-Wnested-externs:N-W*-prototypes:N-Wno-pointer-sign}
+CXXFLAGS ?= ${CFLAGS:N-std=*:N-Wnested-externs:N-W*-prototypes:N-Wno-pointer-sign:S/-ffreestanding/-fno-builtin/g}
CPP ?= cpp
--Apple-Mail-17-543544471--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2A1A4C21-8A2D-4151-BCA0-5FAE1D3BBE86>