From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.windriver.com (mail1.windriver.com [147.11.146.13]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 2D7FAE0149D for ; Tue, 3 Sep 2013 05:37:37 -0700 (PDT) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.14.5/8.14.3) with ESMTP id r83CbbG2022587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Sep 2013 05:37:37 -0700 (PDT) Received: from [128.224.146.67] (128.224.146.67) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.2.347.0; Tue, 3 Sep 2013 05:37:36 -0700 Message-ID: <5225D802.4000802@windriver.com> Date: Tue, 3 Sep 2013 08:37:22 -0400 From: Bruce Ashfield User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Hans_Beck=E9rus?= References: <52254404.4040602@windriver.com> In-Reply-To: Cc: "yocto@yoctoproject.org" Subject: Re: header file missing in populated SDK X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 12:37:44 -0000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit On 13-09-03 04:27 AM, Hans Beckérus wrote: > On Tue, Sep 3, 2013 at 4:05 AM, ChenQi 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 -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 >