On 13-09-03 08:46 AM, Hans Beckérus wrote:
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.
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
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
