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