[yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

[Khem Raj]

> On Oct 5, 2016, at 11:18 AM, Dinh Nguyen (dinhn) <dinhn at cisco.com> wrote:
> 
>>> Are the files present in the image/packages?  Maybe it is just the
>>> bitbake cache skipping doing work it already did last time.
> 
> If I don’t do the bitbake clean, and just do bitbake again, then yes.
> 
> 
> But if I do “bitbake -c clean c-mlib” and bitbake again, the is where the problem.


well its using sstate cache here so when you do clean and rebuild and it notices no changes from previous builds
then it is just going to reuse the build artifacts from last builds and not checkout the sources etc.
all those tasks will be skipped.

why are looking for sources in a build tree ?
I ask because if you want to hack on it then I would recommend following devtool workflow.
see
http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#using-devtool-in-your-workflow


> 
> Thanks,
>  —Dinh
> 
> 
> 
> 
> On 10/5/16, 9:30 AM, "Lennart Sorensen" <lsorense at csclub.uwaterloo.ca> wrote:
> 
>> On Wed, Oct 05, 2016 at 04:06:25PM +0000, Dinh Nguyen (dinhn) wrote:
>>> Many thanks Paul. Your help is greatly appreciated.
>>> 
>>> 1. >>> Like the other responder I would suggest you not set PACKAGES
>>> 
>>> Yes, I did not set the PACKAGES, so -dev, -dbg and main packages were built as shown below:
>>> 
>>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find tmp/deploy | grep c-mlibtmp/deploy/ipk/core2-64/c-mlib-dbg_1.1-r0_core2-64.ipk
>>> tmp/deploy/ipk/core2-64/c-mlib-dev_1.1-r0_core2-64.ipk
>>> tmp/deploy/ipk/core2-64/c-mlib_1.1-r0_core2-64.ipk
>>> tmp/deploy/licenses/c-mlib
>>> 
>>> 2. >>> FILES_${PN}-dev = "${includedir}”
>>> 
>>> I added that to .bb as you suggested so .so file doesn't end up in the ${PN}-dev
>>> Package — No longer see the error mentioned in previous mail. Thx
>>> 
>>> 3. >>> This is what I suspected would happen - these files would normally be part of
>>> the ${PN}-dbg package, but since you've removed that from PACKAGES, they are
>>> ending up unpackaged and that is not allowed.
>>> 
>>> Did you mean the "install -m 0644 xxx yyy” to remove those files from the PACKAGES? How do I copy .so and binaries from my target to the libdir or bindir?
>>> 
>>> After changing the .bb to remove the PACKAGES setting and FILES_${PN}-dev = "${includedir}”
>>> For the very first time, packages were built find, image were created under image directory and c-mlib source is still in the yp workspace as shown below:
>>> 
>>> A.Packages were built
>>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find tmp/deploy | grep c-mlib
>>> tmp/deploy/ipk/core2-64/c-mlib-dbg_1.1-r0_core2-64.ipk
>>> tmp/deploy/ipk/core2-64/c-mlib-dev_1.1-r0_core2-64.ipk
>>> tmp/deploy/ipk/core2-64/c-mlib_1.1-r0_core2-64.ipk
>>> tmp/deploy/licenses/c-mlib
>>> 
>>> B. Source files and the c-mlib git directory still have all the sources (e.g just grep the mlib_api.c)
>>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find . -name "mlib_api.c"
>>> ./tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git/src/mlib_api.c
>>> ./tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/packages-split/c-mlib-dbg/usr/src/debug/c-mlib/1.1-r0/git/src/mlib_api.c
>>> ./tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/package/usr/src/debug/c-mlib/1.1-r0/git/src/mlib_api.c
>>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$
>>> 
>>> C. Image was built as well including binaries and libmlib.so
>>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/bin$ ls -ltr
>>> total 1424
>>> -rw-r--r-- 1 dinhn dinhn 171701 Oct  5 01:17 datamodel_cache
>>> -rw-r--r-- 1 dinhn dinhn 187434 Oct  5 01:17 invoke
>>> -rw-r--r-- 1 dinhn dinhn 184961 Oct  5 01:17 invoke_b
>>> -rw-r--r-- 1 dinhn dinhn 171701 Oct  5 01:17 protocol_infra
>>> -rw-r--r-- 1 dinhn dinhn 191362 Oct  5 01:17 publisher
>>> -rw-r--r-- 1 dinhn dinhn 187084 Oct  5 01:17 rpc-register
>>> -rw-r--r-- 1 dinhn dinhn 179648 Oct  5 01:17 service
>>> -rw-r--r-- 1 dinhn dinhn 174518 Oct  5 01:17 subscriber
>>> 
>>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/bin$ cd ../lib
>>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/lib$ ls -ltr
>>> total 856
>>> -rw-r--r-- 3 dinhn dinhn 872657 Oct  5 01:17 libmlib.so
>>> 
>>> So it is all good for the first time, but thereafter that, if I do clean “bitbake -c clean c-mlib” and “bitbake c-mlib” again.
>>> All packages were build successful, but all data under c-mlib got was gone. Nothing there including .c/h files, image directory etc...
>>> 
>>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git$ ls -ltr
>>> total 0
>>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git$
>>> 
>>> Please give me an idea why how to solve this? Sorry for a long email ;-))
>> 
>> Are the files present in the image/packages?  Maybe it is just the
>> bitbake cache skipping doing work it already did last time.
>> 
>> --
>> Len Sorensen
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20161005/586fd0ce/attachment.pgp>