Re: rpm dependency errors

[Mark Hatle <mark.hatle@windriver.com>]

On 11/15/11 9:06 PM, Michael E Brown wrote:
> On Mon, 2011-11-14 at 22:16 -0600, Michael E Brown wrote:
>> I've now run across this same error in two different contexts, and am
>> having difficulty trying to figure out what is going on
>>
>> First, while building meta-toolchain-sdk, I ran into
>> http://pastebin.com/BT02UYk1
>>   ... cut ...
>> Processing task-core-standalone-gmae-sdk-target-dbg...
>> | error: Failed dependencies:
>> |       libgthread-2.0.so.0 is needed by libgupnp-1.0-3-0.16.1-r0.sh4
>> |       libresolv.so.2 is needed by libgupnp-1.0-3-0.16.1-r0.sh4
>>
>> I've confirmed that the libgupnp rpm has only SH4 binaries in it.
>>
>> Next, while building a custom image, I ran across the same error with
>> portmap and tcp-wrappers:
>>
>> http://pastebin.com/dRb5Dum8
>>
>> Note in the pastebin I extracted tcp-wrappers and 'file' says that
>> everything is SH4.
>
> As a bit more information, I found that when I changed to "package_ipk"
> vs rpm in my local.conf, I was able to do image build and sdk builds
> without incident. So this problem looks like something specific to rpm
> package builds. Is there any solution to this other than just not using
> rpm?

RPM packages contain more dependency information then ipk and deb packages. 
This is not a bug, but a feature.  When using RPM packages not only are 
specified dependencies there, but also soname and file level dependencies.

There is an outstanding item to add these soname and file level dependencies to 
the OE/Yocto deb and ipk implementations as well.

Trust me, if the dependency is failing, then there is something wrong with the 
packages or the binaries within the packages (or they're not compatible with the 
elfutils mechanisms used to dump that information.)

You really do need to understand the actual files present in the packages, and 
if they have the corresponding sonames that the dependent packages are looking for.

If you post your layer somewhere, I can attempt to reproduce the problem.

--Mark

> --
> Michael
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto