Re: [yocto] Custom Kernel Recipe Compilation Error.

[Paul Gortmaker <paulg@kernel.org>]

[Re: [yocto] Custom Kernel Recipe Compilation Error.] On 08/07/2025 (Tue 11:06) Gyorgy Sarvari via lists.yoctoproject.org wrote:

> On 7/7/25 22:10, C Larbi via lists.yoctoproject.org wrote:
> > Hello all
> > I am a newbie to the yocto project and on a journey to understand the basics.
> >
> > My reference hardware for my learning journey is the Orange pi 3b (RK3566 soc)
> >
> > I have created a bsp layer containing my machine configuration and a
> > recipe to build a custom kernel.
> >
> > The kernel recipe build throws an error on the "do_compile_kernelmodules" task.
> > Before writing this, i went through the manual process of compiling
> > the same kernel source on my machine and i was able to produce a
> > vmlinux file and build the modules.
> >
> > This is the error from the yocto build process.
> >
> > |   GEN     Makefile
> > |   CALL    /home/cerezo/yocto/tut/poky/build/tmp/work-shared/opi3b/kernel-source/scripts/checksyscalls.sh
> > |   CC [M]  drivers/net/wireless/rockchip_wlan/rkwifi/bcmdhd/aiutils.o
> > |   CC [M]  drivers/net/wireless/rockchip_wlan/rkwifi/bcmdhd/siutils.o
> > | /home/cerezo/yocto/tut/poky/build/tmp/work-shared/opi3b/kernel-source/drivers/net/wireless/rockchip_wlan/rkwifi/bcmdhd/aiutils.c:44:10:
> > fatal error: typedefs.h: No such file or directory
> > |    44 | #include <typedefs.h>
> > |       |          ^~~~~~~~~~~~
> > | compilation terminated.

I saw this, and I'm thinking that include shouldn't be there at all.
You might in turn ask "Why would you say that?" -- well, experience?

Let us have a quick look at a current kernel.

	linux-head$ git grep '#include <typedefs.h>'
	linux-head$ git grep '#include .*typedefs.h>'
	linux-head$ git grep '#include .*module.h>' | wc -l
	14342
	linux-head$ 

No instances of <typedefs.h>.  Also no instances of <somepath/typedefs.h>.
And if I search for a common include, like module.h, there are tens of
thousands of instances, so my search isn't somehow fundamentally broken.

> > | make[7]: *** [/home/cerezo/yocto/tut/poky/build/tmp/work-shared/opi3b/kernel-source/scripts/Makefile.build:250:
> > drivers/net/wireless/rockchip_wlan/rkwifi/bcmdhd/aiutils.o] Error 1
> > | make[7]: *** Waiting for unfinished jobs....
> >
> > Will really appreciate if i can get some pointers as to what i may be
> > doing wrong.
> 
> This seems to be a recurring problem with this particular vendor kernel
> unfortunately. Take a look at this patch which solves the same issue on
> a different branch:
> https://github.com/riscv/meta-riscv/blob/master/recipes-kernel/linux/linux-orangepi/orangepi-rv2/bcmdhd-fix-typedefs-header-not-found.patch

So this patch amounts to the one line change as follows:

	 EXTRA_CFLAGS += -I$(BCMDHD_ROOT)/include/ -I$(BCMDHD_ROOT)/
	+EXTRA_CFLAGS += -I$(srctree)/$(src)/include
	 ifeq ($(CONFIG_BCMDHD),m)

OK, that probably does put a (semi random) instance of typedefs.h into
the header search path, but given what I've shown above in the mainline
kernel tree, I would ask if anyone has checked what happens if the
offending typedefs.h include line was simply *removed*?  Does the error
go away, or does it give a more informative error on exactly what
specific definition is missing - so that folks can fix it "properly"?

You generally don't want the kernel and kernel drivers pulling in
include paths from random locations outside the kernel. The kernel is
designed to be self-contained, with the exception of the few user space
utilities that happen to be bundled with the kernel for convenience.

In a case like this, the patch risks causing additional errors elsewhere.
Things like "conflicting definitions for XYZ".  Or worse, you could get
an instance where an added include presents a "struct foo" that is
different from the kernel's view of what "struct foo" is - say for
example the kernel's version uses a u64 instead of a u32, or has padding
for cache line alignment and performance reasons.  Then your stuff will
just silently compile, but explode at runtime.  Kind of a classic case
of "two wrongs don't make a right".

This is one (of many) problems with not-in-mainline drivers like this.
The various SoC engineers tasked with creating a driver develop their
own ways of doing things, but it remains largely unreviewed by the
larger group of people out there, including the subsystem maintainers
who would spot things like this and require it to be done properly
before accepting it into their local tree and then requesting it to be
merged upwards into mainline.

Paul.
--

> 
> I think adapting this to your branch should solve your problem too.
> 
> 
> >
> > KERNEL RECIPE
> > https://github.com/AccraNET/meta-orspace-orangepi3b/blob/main/recipes-kernel/linux/linux-orangepi.bb
> >
> > MACHINE CONFIGURATION
> > https://github.com/AccraNET/meta-orspace-orangepi3b/blob/main/conf/machine/opi3b.conf
> >
> > Best Regards
> > Cerezo
> >