* header file missing in populated SDK
@ 2013-09-02 14:56 Hans Beckérus
2013-09-03 2:05 ` ChenQi
0 siblings, 1 reply; 6+ messages in thread
From: Hans Beckérus @ 2013-09-02 14:56 UTC (permalink / raw)
To: yocto@yoctoproject.org
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
}
foo.h ends up ok in our build/tmp/sysroots, 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: header file missing in populated SDK
2013-09-02 14:56 header file missing in populated SDK Hans Beckérus
@ 2013-09-03 2:05 ` ChenQi
2013-09-03 8:27 ` Hans Beckérus
0 siblings, 1 reply; 6+ messages in thread
From: ChenQi @ 2013-09-03 2:05 UTC (permalink / raw)
To: yocto
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.
> 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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: header file missing in populated SDK
2013-09-03 2:05 ` ChenQi
@ 2013-09-03 8:27 ` Hans Beckérus
2013-09-03 12:37 ` Bruce Ashfield
0 siblings, 1 reply; 6+ messages in thread
From: Hans Beckérus @ 2013-09-03 8:27 UTC (permalink / raw)
To: ChenQi; +Cc: yocto@yoctoproject.org
On Tue, Sep 3, 2013 at 4:05 AM, ChenQi <Qi.Chen@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.
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@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: header file missing in populated SDK
2013-09-03 8:27 ` Hans Beckérus
@ 2013-09-03 12:37 ` Bruce Ashfield
2013-09-03 12:46 ` Hans Beckérus
0 siblings, 1 reply; 6+ messages in thread
From: Bruce Ashfield @ 2013-09-03 12:37 UTC (permalink / raw)
To: Hans Beckérus; +Cc: yocto@yoctoproject.org
On 13-09-03 04:27 AM, Hans Beckérus wrote:
> On Tue, Sep 3, 2013 at 4:05 AM, ChenQi <Qi.Chen@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@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: header file missing in populated SDK
2013-09-03 12:37 ` Bruce Ashfield
@ 2013-09-03 12:46 ` Hans Beckérus
2013-09-03 15:27 ` Bruce Ashfield
0 siblings, 1 reply; 6+ messages in thread
From: Hans Beckérus @ 2013-09-03 12:46 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: yocto@yoctoproject.org
On Tue, Sep 3, 2013 at 2:37 PM, Bruce Ashfield
<bruce.ashfield@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@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@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: header file missing in populated SDK
2013-09-03 12:46 ` Hans Beckérus
@ 2013-09-03 15:27 ` Bruce Ashfield
0 siblings, 0 replies; 6+ messages in thread
From: Bruce Ashfield @ 2013-09-03 15:27 UTC (permalink / raw)
To: Hans Beckérus; +Cc: yocto@yoctoproject.org
On 13-09-03 08:46 AM, Hans Beckérus wrote:
> On Tue, Sep 3, 2013 at 2:37 PM, Bruce Ashfield
> <bruce.ashfield@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@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@yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-09-03 15:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-02 14:56 header file missing in populated SDK Hans Beckérus
2013-09-03 2:05 ` ChenQi
2013-09-03 8:27 ` Hans Beckérus
2013-09-03 12:37 ` Bruce Ashfield
2013-09-03 12:46 ` Hans Beckérus
2013-09-03 15:27 ` Bruce Ashfield
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.