Re: Patch for fixing build issues with external kernel modules.

[Franz Leitl <leitl@fim.uni-passau.de>]

Hi,

Am Dienstag 10 Mai 2011, 03:40:04 schrieb Franz Leitl:
> Am Montag 09 Mai 2011, 22:53:19 schrieben Sie:
> > The kernel should not remove bounds.h, that is documented in the
> > Makefile. If it does, it's a bug.
> 
> After executing "bitbake -f -c compile virtual/kernel"  I get bounds.h in
> "${S}/includes/generated/".
> Seems as if both
>     oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
> and
>     make -C $kerneldir _mrproper_scripts
> in kernel.bbclass are to blame for removing bounds.h from
> "$kerneldir/includes/generated/".
> I tested it twice. Only in case both lines are commented out bounds.h stays
> in "$kerneldir/includes/generated/"
I still would like to know, what to do next.

> What to do with module.bbclass not setting KERNEL_PATH in
> module_do_install? My Makefile relies on it, if KERNEL_PATH is not set it
> will use
> "/lib/modules/$(shell uname -r)/build" instead. But uname returns the
> host's kernel version.
> Is there any reason why oe_runmake in module_do_compile sets
> "KERNEL_PATH=${STAGING_KERNEL_DIR}" while in module_do_install it doesn't?
> Should I overwrite the do_install in my recipe or should module.bbclass be
> fixed?
Ok, I just remembered the hint to recipes-kernel/hello-mod/files/Makefile. Works 
as KERNEL_SRC is also set to ${STAGING_KERNEL_DIR}. But it does not explain what 
the real difference between KERNEL_SRC and KERNEL_PATH is, as both are set to 
the same value and why does module_do_install not set KERNEL_PATH but 
module_do_compile does?


Regards,
Franz