[OE-core] Patch for fixing build issues with external kernel modules.
Franz Leitl
leitl at fim.uni-passau.de
Tue May 10 01:40:04 UTC 2011
Hi,
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/".
What to do next?
> It's just about fixing it properly instead of applying a band-aid.
> Regenerating something that shouldn't have been deleted in the first
> place is a band-aid, and you can go that route in your own recipe if you
> like (per Koen's patch), but that doesn't belong in the core kernel
> classes.
I prefer a proper fix, whatever it might look like.
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?
Regards,
Franz
More information about the Openembedded-core
mailing list