From: Darren Hart <dvhart@linux.intel.com>
To: Koen Kooi <koen@dominion.thruhere.net>
Cc: Bruce Ashfield <Bruce.Ashfield@windriver.com>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [RFC] don't run make clean on kernel_do_install
Date: Thu, 28 Apr 2011 08:26:12 -0700 [thread overview]
Message-ID: <4DB98714.4030201@linux.intel.com> (raw)
In-Reply-To: <D13D255E-BAA6-4F92-94CB-CF0706779365@dominion.thruhere.net>
On 04/28/2011 01:30 AM, Koen Kooi wrote:
>
> Op 25 apr 2011, om 19:10 heeft Darren Hart het volgende geschreven:
>
>> Hi Koen,
>>
>> On 04/23/2011 07:47 AM, Koen Kooi wrote:
>>> Hi,
>>>
>>> Over the holidays I was trying to build some externel kernel modules
>>> and they failed to build because linux/bounds.h wasn't in sysroots.
>>>
>>
>>
>> According the the linux Makefile:
>>
>> ###
>> # Cleaning is done on three levels.
>> # make clean Delete most generated files
>> # Leave enough to build external modules
>>
>> The kernel Makefile should not be deleting it.
>>
>> And indeed:
>> https://bugzilla.kernel.org/show_bug.cgi?id=11475
>>
>> This was addressed by the following in 2.6.27:
>> 7d3cc8b6d899e53222c22a78d98bb53a695f7962
>> Don't clean bounds.h and asm-offsets.h
>>
>> Later, bounds.h moved as well in 2.6.33:
>> 01fc0ac198eabcbf460e1ed058860a935b6c2c9a
>> kbuild: move bounds.h to include/generated
>>
>>
>> Which kernel version are you attempting to build?
>>
>> We shouldn't add code to address a bug in a specific kernel version in a
>> kernel base class. That belongs in the specific recipe. I suggest trying
>> to add the 7d3cc8b6d899e53222c22a78d98bb53a695f7962 patch to your kernel
>> recipe and see if that resolves the issue for you without resorting to
>> recreating the clean process in the base class.
>
> I went with this option: http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/commit/?id=7bcba149f05cc9c5d8ce956ee40e2c6849601470
>
Works around the problem, but does so in the appropriate place. I would
like to understand if this is something that is likely to bite others,
or if there is something peculiar about this particular kernel. If it
crops up again, we'll need to dig in further.
--
Darren
> regards,
>
> Koen
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
prev parent reply other threads:[~2011-04-28 15:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-23 14:47 [RFC] don't run make clean on kernel_do_install Koen Kooi
2011-04-25 17:10 ` Darren Hart
2011-04-25 18:28 ` Koen Kooi
2011-04-28 8:30 ` Koen Kooi
2011-04-28 15:26 ` Darren Hart [this message]
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=4DB98714.4030201@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=Bruce.Ashfield@windriver.com \
--cc=koen@dominion.thruhere.net \
--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