[yocto] how to copy a tar file to Root file system

[Paul Eggleton]

On Wed, 02 Nov 2016 20:17:11 Swapna.Gurumani at microchip.com wrote:
> > In any case, when debugging situations like this it helps to make a fresh
> > start - run "bitbake -c clean crank" (you don't need -c cleansstate
> > because being stuck at do_install you haven't got to any real sstate tasks
> > yet). Then methodically run through each task - when do_unpack ran what
> > got unpacked into ${WORKDIR}? If that's as expected, what got put into
> > ${D} (which is the "image" subdirectory under ${WORKDIR})? Does what's in
> > ${D} match up with the layout you expect to be on the target? At any time
> > you can use "bitbake -e crank | less" to inspect the value of variables.
> > You can also see exactly what commands got run within the task by looking
> > at the run.do_* files under "temp" in the workdir.
>
> ANSWER >> All this looks good. The run.do* files don't show much. Although,
> why am I seeing stuff like: NOTE: arm-poky-linux-gnueabi-objdump -p
> /home/swapna/workspace/work/yocto/poky/build-atmel/tmp/work/cortexa5hf-neon
> -poky-linux-gnueabi/crank/1.0-r0/packages-split/crank/opt/crank/linux-sama5d
> -armle-fbdev-obj/lib/luagretest.so In log.do_package_qa?

There are various QA checks on the output (as you've no doubt seen) - some of
those require examining binaries such as the checks on rpaths, and that
requires running objdump.

> > * Based on what you've said earlier, your S value cannot be correct - it
> > may not matter, but it might as well be fixed anyway. If the tarball
> > unpacks a "crank" subdirectory then it should be set to
> > "${WORKDIR}/crank".
> 
> ANSWER >> I get the same error no matter what the S is set to:
> non -staticdev package contains static .a library: crank path
> 'work/cortexa5hf-neon-poky-linux-gnueabi/crank/1.0-r0/packages-split/crank/
> opt/crank/linux-sama5d-armle-fbdev-obj/lib/libssgf.a' [staticdev]
> 
> WHY am I getting this error?

That error has nothing to do with the S value - as I mentioned, S may not
matter in this case, but it might as well be correct if you're setting it at
all.

You resolved this issue in the end, but for future reference there is a guide
on how to deal with various QA errors/warnings here:

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-errors-and-warnings
 
> > * Setting DEPENDS isn't really doing you any good - DEPENDS is for
> > build-time dependencies. You're only unpacking a tarball, you don't need
> > any build-time dependencies to speak of. If you have runtime dependencies
> > then set them in RDEPENDS_${PN} since that's where runtime dependencies
> > need to be set.
>
> ANSWER>> without that line, I get the following error:
> 
> WARNING: crank-1.0-r0 do_package_qa: QA Issue: crank rdepends on tslib, but
> it isn't a build dependency, missing tslib in DEPENDS or PACKAGECONFIG?
> [build-deps] 
> WARNING: crank-1.0-r0 do_package_qa: QA Issue: crank rdepends
> on libasound, but it isn't a build dependency, missing alsa-lib in DEPENDS
> or PACKAGECONFIG? [build-deps]
 
That message is slightly misleading - in this case it really is just a runtime
dependency (since you're not building anything) and you should be able to
resolve it by setting RDEPENDS_${PN} rather than DEPENDS.

> > * As another responder pointed out, the inherit of pkgconfig isn't needed
> > - you don't need pkg-config for anything being done here. 
>
> Again, same error with or without this. Or even if I use " inherit bin_package"

Again, this isn't related to those errors, pkg-config just isn't necessary
for what this recipe does. 

FYI, bin_package is more suited to packages whose layout is already prepared
for the target (e.g. if you had an rpm or deb file) - you could have used it
here, but I'm not entirely sure it would have made things much easier given
the issues you ran into.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre