From: Darren Hart <dvhart@linux.intel.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: Patch for fixing build issues with external kernel modules.
Date: Tue, 10 May 2011 13:23:13 -0700 [thread overview]
Message-ID: <4DC99EB1.1090506@linux.intel.com> (raw)
In-Reply-To: <201105100356.05227.leitl@fim.uni-passau.de>
Hi Franz, I'm not ignoring you, I'm laid up in bed with a nasty stomach
flu and not thinking very clearly right now. I'll try and responds as
soon as I can...
--
Darren
On 05/09/2011 06:56 PM, Franz Leitl wrote:
> 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
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
next prev parent reply other threads:[~2011-05-10 20:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-08 22:16 Patch for fixing build issues with external kernel modules Franz Leitl
2011-05-08 22:30 ` Franz Leitl
2011-05-09 16:28 ` Darren Hart
2011-05-09 17:32 ` Franz Leitl
2011-05-09 17:53 ` Koen Kooi
2011-05-09 18:23 ` Darren Hart
2011-05-09 18:38 ` Franz Leitl
2011-05-09 20:53 ` Darren Hart
2011-05-10 1:40 ` Franz Leitl
2011-05-10 1:56 ` Franz Leitl
2011-05-10 20:23 ` Darren Hart [this message]
2011-05-10 22:50 ` Franz Leitl
2011-05-23 23:37 ` Darren Hart
2011-05-24 0:19 ` Darren Hart
2011-05-09 18:20 ` Darren Hart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DC99EB1.1090506@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox