>> yes thats normal when package is re-used from sstate-cache Many thanks Khem. Got it, so the IPK packages were built early is OK. I did a clean all and redo the bitbake, all packages, images were rebuilt.
Thanks again, —Dinh > >> On Oct 5, 2016, at 11:43 AM, Dinh Nguyen (dinhn) <di...@cisco.com> wrote: >> >> >> >>>> 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 ? >> >> >> Not only source under >> .. yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git >> >> But other data such as such as the >> yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/* was also gone. The >> following image that I have it in the first place. > >yes thats normal when package is re-used from sstate-cache >> >> >> >> dinhn@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@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@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 >> >> >> Thanks, >> —Dinh >> >> On 10/5/16, 11:26 AM, "Khem Raj" <raj.k...@gmail.com> wrote: >> >>> >>>> On Oct 5, 2016, at 11:18 AM, Dinh Nguyen (dinhn) <di...@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" <lsore...@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@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@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@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@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ >>>>>> >>>>>> C. Image was built as well including binaries and libmlib.so >>>>>> dinhn@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@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@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@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@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@yoctoproject.org >>>> https://lists.yoctoproject.org/listinfo/yocto >>> > -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
