[yocto] header file missing in populated SDK

[Hans Beckérus]

On Tue, Sep 3, 2013 at 2:37 PM, Bruce Ashfield
<bruce.ashfield at windriver.com> wrote:
> 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.
>
Definitely not. This is a unique header bound to a kernel module that
is needed by user-space for ioctl() handling etc. In this case I think
/usr/include/linux is actually the proper place for this.

Thanks.
Hans

> 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
>>
>