[OE-core] [PATCH 1/1] kernel: restore scripts in the sysroot

Bruce Ashfield bruce.ashfield at gmail.com
Wed Nov 20 04:43:56 UTC 2013


On Tue, Nov 19, 2013 at 9:59 PM, Khem Raj <raj.khem at gmail.com> wrote:
>
> On Nov 19, 2013, at 2:45 PM, Richard Purdie <richard.purdie at linuxfoundation.org> wrote:
>
>> On Tue, 2013-11-19 at 14:39 -0800, Khem Raj wrote:
>>> On Nov 19, 2013, at 2:36 PM, Richard Purdie <richard.purdie at linuxfoundation.org> wrote:
>>>
>>>> On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:
>>>>
>>>>> Well reproducer case is that build from sstate but such that an external module needs to be rebuilt
>>>>> if external module also comes from sstate then it all is fine. Its only when everything is coming from
>>>>> sstate except this external module which needs to be rebuilt then you see this problem.
>>>>>
>>>>> now, I see the code in module-base.class
>>>>>
>>>>> #
>>>>> # Ensure the hostprogs are available for module compilation. Modules that
>>>>> # inherit this recipe and override do_compile() should be sure to call
>>>>> # do_make_scripts() or ensure the scripts are built independently.
>>>>> #
>>>>> do_make_scripts() {
>>>>>       unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>>>>>       make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
>>>>>                  -C ${STAGING_KERNEL_DIR} scripts
>>>>> }
>>>>>
>>>>> so it expects that, do_make_scripts is explicitly called by external module recipes
>>>>>
>>>>> and my recipes did override module_do_compile task but not do_compile like below
>>>>>
>>>>> module_do_compile() {
>>>>>       oe_runmake
>>>>> }
>>>>>
>>>>> so, is comment wrong there should it say module_do_compile instead ?
>>>>>
>>>>> will it work with sstate always ?
>>>>>
>>>>> it will be OK to revert it if thats the case.
>>>>
>>>> Did you inherit module-base or module? I think the wording applies to
>>>> module and not module-base. I think the function used to be in module
>>>> and was moved along with the comment which is now incorrect.
>>>>
>>>
>>> inherit module
>>
>> So in that case there is:
>>
>> addtask make_scripts after do_patch before do_compile
>> do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
>> do_make_scripts[deptask] = “do_populate_sysroot”
>>
>
> yes I see.
>
>
>> which forces the make_scripts task to run before compile. I don't see
>> how that could therefore fail? :/
>>
>> Do you have a copy of the exact log?
>
> Not anymore, it was sometime ago, the logs are unfortunately recycled.
>
>> I'm wondering if this is another
>> variant of the bitbake dependency bug I just tracked down
>> (http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=7b49d336c4672f3dfa78e1c3f1f5c7384264a118)
>>
>
> ah very likely, I think I will try this fix and revert the kernel.bbclass fix locally and see if I still am
> able to reproduce this issue. In any case I think the kernel.bbclass may be abandoned since I now think it
> was a wrong fix although it did fix the problem
>

Agreed.

Since you have control over your recipes, you don't have to worry
about some of the more evil ones that build, and inside their own build head
reference the kernel-staging tree and attempt to build modules. Just getting
the right inheritance should fix it up.

The other case is a different concern, and even then, including module, and
overriding the do_compile() should work to get the scripts restored and not
just attempt to launch a build.

I'm going to be in Transit tomorrow, so won't be all that responsive, but
my vote is now to simply revert the sstate scripts changes once Khem confirms
that he is ok for his builds.

Cheers,

Bruce

>> Cheers,
>>
>> Richard
>>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"



More information about the Openembedded-core mailing list