On Tue, Sep 3, 2013 at 2:37 PM, Bruce Ashfield <bruce.ashfi...@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.c...@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 >> > _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto