Thanks Khem >> I guess its getting renamed as per debian package renaming rules. Just add >> ALLOW_EMPTY_${PN} = "1"
I added ALLOW_EMPTY_${PN} = “1” And encountered the same issue as specified in previous mail. For the very first time after adding it, everything went well, including the -dev, -dbg and main ipk packages and image were built. All source files under c-mlib git is there. Subsequence bitbake -c clean c-mlib and bitbake c-mlib, ipk packages were built, but c-mlib git directory became empty. 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 Thanks much, —Dinh On 10/5/16, 9:52 AM, "Khem Raj" <raj.k...@gmail.com> wrote: >On Wed, Oct 5, 2016 at 9:06 AM, Dinh Nguyen (dinhn) <di...@cisco.com> 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 ;-)) > >I guess its getting renamed as per debian package renaming rules. Just add > >ALLOW_EMPTY_${PN} = "1" > >and see if you get the ipk > >> >> Best, >> —Dinh >> >> >> >> >> >> On 10/4/16, 11:55 PM, "Paul Eggleton" <paul.eggle...@linux.intel.com> wrote: >> >>>On Wed, 05 Oct 2016 05:12:27 Dinh Nguyen wrote: >>>> Thanks much Paul. >>>> >>>> >>>> PACKAGES = "${PN}" should work >>>> >>>> It solved the early error “ c-mlib listed in PACKAGES multiple times, this >>>> leads to packaging errors” — Thanks again. >>>> >>>> >>>> But running into other issue. Below is my do_install >>>> >>>> do_install () { >>>> oe_runmake all >>>> install -d ${D}${libdir} >>>> install -d ${D}${bindir} >>>> install -m 0644 ${S}/target/libmlib.so ${D}${libdir} >>>> install -m 0644 ${S}/target/datamodel_cache ${D}${bindir} >>>> install -m 0644 ${S}/target/invoke ${D}${bindir} >>>> install -m 0644 ${S}/target/invoke_b ${D}${bindir} >>>> install -m 0644 ${S}/target/protocol_infra ${D}${bindir} >>>> install -m 0644 ${S}/target/publisher ${D}${bindir} >>>> install -m 0644 ${S}/target/rpc-register ${D}${bindir} >>>> install -m 0644 ${S}/target/service ${D}${bindir} >>>> install -m 0644 ${S}/target/subscriber ${D}${bindir} >>>> } >>>> >>>> PACKAGES = "${PN}" >>>> FILES_${PN} = "/usr/bin/datamodel_cache \ >>>> /usr/bin/invoke \ >>>> /usr/bin/invoke_b \ >>>> /usr/lib/libmlib.so \ >>>> /usr/bin/protocol_infra \ >>>> /usr/bin/publisher \ >>>> /usr/bin/rpc-register \ >>>> /usr/bin/service \ >>>> /usr/bin/subscriber" >>>> >>>> >>>> >>>> And under ${S}/target, it has the libmlib.so and other binaries built, >>>> And I intended to copy the .so to ${D}${libdir} and binarires to >>>> ${D}${bindir}. I am able to build the c-mlib package as shown below: >>> >>>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find >>>> tmp/deploy | grep c-mlib >>>> tmp/deploy/ipk/core2-64/c-mlib_1.1-r0_core2-64.ipk >>>> >>>> >>>> The problem is that, after "bitbake c-mlib”, it moved all sources under >>>> ${S} >>>> to /usr/src/debug etc.. >>>> I googled but unable to find the root cause. >>>> Would you and other can help to identify the issue? >>>> NOTE: Executing RunQueue Tasks >>>> ERROR: QA Issue: c-mlib: Files/directories were installed but not shipped >>>> /usr/src >>>> /usr/lib/.debug >>>> /usr/lib/.debug/libmlib.so >>>> /usr/src/debug >>>> /usr/src/debug/c-mlib >>>> /usr/src/debug/c-mlib/1.1-r0 >>>> /usr/src/debug/c-mlib/1.1-r0/git >>>> /usr/src/debug/c-mlib/1.1-r0/git/src >>>> /usr/src/debug/c-mlib/1.1-r0/git/include >>>> /usr/src/debug/c-mlib/1.1-r0/git/deps >>>> /usr/src/debug/c-mlib/1.1-r0/git/src/mlib_api.c >>>> /usr/src/debug/c-mlib/1.1-r0/git/src/mlib_metrics.c >>>> /usr/src/debug/c-mlib/1.1-r0/git/src/mlib_util.c >>>> /usr/src/debug/c-mlib/1.1-r0/git/src/mlib_local_metrics.c >>>> /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings >>>> /usr/src/debug/c-mlib/1.1-r0/git/src/utils >>>> /usr/src/debug/c-mlib/1.1-r0/git/src/service_sdk >>>> /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings/mlib_service_cache.c >>>> /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings/mlib_wrapper.c >>>> /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings/mlib_dsa.c >>>> /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings/include >>>> …. >>> >>>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. >>> >>>Like the other responder I would suggest you not set PACKAGES - instead you >>>just need to take steps so that the .so file doesn't end up in the ${PN}-dev >>>package. You could do something like this: >>> >>>FILES_${PN}-dev = "${includedir}" >>> >>>Cheers, >>>Paul >>> >>>-- >>> >>>Paul Eggleton >>>Intel Open Source Technology Centre >> -- >> _______________________________________________ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto