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
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
