Re: Cannot satisfy the following dependencies for task-core-basic: libusb-compat (>= 0.1.3)

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2012-02-22 at 11:52 -0500, Brandon Stafford wrote:
> On Wed, Feb 22, 2012 at 7:12 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > The first question is did it build libusb-compat at all? Are there any
> > stamps for this in tmp/stamps/*/libusb-compat* or files in
> > tmp/work/*/libusb-compat* that would suggest that it did?
> 
> Thanks for the suggestions, Richard. Answers below.
> 
> Yes, some stamps exist, but fewer than I would expect. I don't see a
> do_compile step.
> 
> :~/oe-core/build/tmp-eglibc/stamps$ find . -name libusb-compat*
> ./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_package_write
> ./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_populate_lic_setscene
> ./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_package_setscene.qemuarm
> ./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_package_write_ipk_setscene
> ./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_populate_sysroot_setscene.qemuarm

What this means is that it build libusb-compat from the sstate cache
rather than building it completely from scratch. The
do_package_write_ipk_setscene in particular means it should have
installed some .ipk files into tmp/deploy/ipk/.

> However, it does look like binaries were created. For example, here is
> a 13 kB ELF file:
> tmp-eglibc/work/armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3/packages-split/libusb-compat/lib/libusb-0.1.so.4.4.4
> 
> :~/oe-core/build/tmp-eglibc/work/armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3$
> ls -lh packages-split/libusb-compat/lib
> total 16K
> lrwxrwxrwx 1 rascal rascal  19 2012-02-14 09:03 libusb-0.1.so.4 ->
> libusb-0.1.so.4.4.4
> -rwxr-xr-x 1 rascal rascal 13K 2012-02-14 09:03 libusb-0.1.so.4.4.4
> :~/oe-core/build/tmp-eglibc/work/armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3$
> file packages-split/libusb-compat/lib/libusb-0.1.so.4.4.4
> packages-split/libusb-compat/lib/libusb-0.1.so.4.4.4: ELF 32-bit LSB
> shared object, ARM, version 1 (SYSV), dynamically linked, stripped
> 
> > Secondly, did it place any libusb-compat package into tmp/deploy/ipk/* ?
> 
> It did not:
> 
> :~/oe-core/build/tmp-eglibc/deploy/ipk$ find . -name libusb-compat*
> 
> However, there are a bunch of libusb packages:
> 
> :~/oe-core/build/tmp-eglibc/deploy/ipk$ find . -name libusb*
> ./armv5te/libusb-0.1-dbg_0.1.3-r3_armv5te.ipk
> ./armv5te/libusb-1.0-0_1.0.8-r3_armv5te.ipk
> ./armv5te/libusb-1.0-dbg_1.0.8-r3_armv5te.ipk
> ./armv5te/libusb-1.0-dev_1.0.8-r3_armv5te.ipk
> ./armv5te/libusb-1.0-staticdev_1.0.8-r3_armv5te.ipk
> ./armv5te/libusb-0.1-dev_0.1.3-r3_armv5te.ipk
> ./armv5te/libusb-0.1-4_0.1.3-r3_armv5te.ipk
> ./armv5te/libusb-0.1-staticdev_0.1.3-r3_armv5te.ipk

I think the library renaming code is renaming "libusb-compat" to a
package called "libusb-0.1" using the 'debian' renaming code. Your
packages are therefore present.

> If I understand how do_rootfs works from
> http://docs.openembedded.org/usermanual/usermanual.html#rootfs_ipkg_class,
> it seems like the ipk is not being built correctly, so do_rootfs can't
> pull it into the filesystem image.
> 
> I'm not sure where to go from here. It looks like at least some code
> was compiled, but somehow it's not getting packaged right.

It appears for some reason the system wants a "libusb-compat" when it
should be looking for a "libusb-0.1". This would imply that somewhere,
the renaming failed, either in the dependencies of some package, or at
the rootfs creation point itself.

If you look at the tmp/deploy/ipk/*/Packages index file, you should see
the dependencies of each package listed. It would be interesting to see
if something is depending on "libusb-compat". If there is something I'd
be tempted to try running "bitbake xxx -c cleansstate" and rebuilding
that specific recipe.

If there is nothing listing libusb-compat in index, the problem is in
the rootfs step itself.

Cheers,

Richard