[yocto] header file missing in populated SDK

Bruce Ashfield bruce.ashfield at windriver.com
Tue Sep 3 05:37:22 PDT 2013


On 13-09-03 04:27 AM, Hans Beckérus wrote:
> On Tue, Sep 3, 2013 at 4:05 AM, ChenQi <Qi.Chen at windriver.com> wrote:
>> On 09/02/2013 10:56 PM, Hans Beckérus wrote:
>>>
>>> Hi. We are having some issues figuring out why one of our header files
>>> fails to be installed properly into the SDK. The header file is
>>> currently installed using a few lines in one of our recipe:
>>>
>>> do_install_append() {
>>>           install -m 0644 ${S}/foo.h
>>> ${STAGING_DIR}/${MACHINE}${includedir}/linux/foo.h
>>> }
>>
>> Please don't do that.
>> I think just installing the foo.h into the ${D}${includedir} would do. And
>> foo.h will end up in the FOO-dev package.
>> Make sure that the FOO package is in the IMAGE_INSTALL list, and then use
>> 'bitbake <your-image-recipe> -cpopulate_sdk' command to populate the SDK.
>>
> Note taken ;) Actually this was a very old recipe so I guess that
> could be one of the reason why it was done this way. Changing
> do_install_append to:
>
> do_install_append() {
>          install -d ${D}${includedir}/linux
>          install -m 644 ${S}/foo.h ${D}${includedir}/linux/foo.h
> }
>
> solves the problem!
> The staging dir is automatically updated and the SDK is also populated
> as it should.

I do have another word of caution here. "/usr/include/linux" is where the
linux-libc-headers are installed and occupy. Individual packages and
applications shouldn't be installing into that infrastructure unless
they know what they are doing.

If you are creating a new file, you'll be ok, but never modify an
existing exported .h file from the linux kernel, your results won't be
what you expect.

Cheers,

Bruce

> Actually, I did not need to add package FOO to the IMAGE_INSTALL since
> it is a kernel module and installed as part of 'kernel-modules'.
> I think we once tried to solve the same issue without
> do_install_append() instead using FILES,
> but to me FILES is still a piece of black magic. I have never really
> managed to figure out how FILES_${PN} manages to locate the actual
> source file since it only lists destination targets?
>
> Thanks,
> Hans
>
>
>
>>
>>> foo.h ends up ok in our build/tmp/sysroots,
>>
>> sysroots != SDK
>> The files under build/tmp/sysroots are usually generated by the
>> do_populate_sysroot task of each recipe.
>>
>>  From my understanding, SDK is composed of two parts, the target part and the
>> nativesdk part.
>> The nativesdk part is determined by the TOOLCHAIN_HOST_TASK.
>> And the target part is determined by the TOOLCHAIN_TARGET_TASK.
>> The reason that we could only ensure that FOO is in IMAGE_INSTALL is because
>> in image.bbclass, we have:
>> TOOLCHAIN_TARGET_TASK += "${PACKAGE_INSTALL}"
>> export PACKAGE_INSTALL ?= "${IMAGE_INSTALL} ${ROOTFS_BOOTSTRAP_INSTALL}
>> ${FEATURE_INSTALL}"
>>
>> The process of populating SDK is also composed of two parts, installing the
>> target packages and installing the nativesdk packages. See
>> populate_sdk_xxx.bbclass for more details.
>>
>> Best Regards,
>> Chen Qi
>>
>>>    but it does not make it to the SDK.
>>> Is our do_install_append wrong in some way, does it have to be updated
>>> to support SDK builds? Maybe it is wrong to use ${MACHINE} here?
>>>
>>> Thanks.
>>> Hans
>>> _______________________________________________
>>> yocto mailing list
>>> yocto at yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>




More information about the yocto mailing list