[yocto] header file missing in populated SDK

[Bruce Ashfield]

On 13-09-03 08:46 AM, Hans Beckérus wrote:
> 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.

If you need it in the SDK, then absolutely. The other options to solve
this issue for tightly coupled packages is to have them look at the
kernel source directly (the staged version), since by definition if
they are dependent on a kernel header, they are already machine specific.

Cheers,

Bruce

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