[OE-core] [dizzy][PATCH] package.bbclass: Fix support for private libs

[akuster808]

thanks for the reminder. I have pulled into my staging work.

-armin

On 01/29/2015 04:41 AM, Martin Jansa wrote:
> On Sun, Jan 18, 2015 at 05:12:13PM +0100, Martin Jansa wrote:
>> * n is a tuple since this commit:
>>    commit d3aa7668a9f001044d0a0f1ba2de425a36056102
>>    Author: Richard Purdie <richard.purdie at linuxfoundation.org>
>>    Date:   Mon Jul 7 18:41:23 2014 +0100
>>    Subject package.bbclass: Improve shlibs needed data structure
>>
>>    since then 'n in private_libs' was always false and private libs
>>    were always processed
>> * this is bad when we have libfoo in private libs, but also some package
>>    providing libfoo, that way we ship own libfoo.so, but together with
>>    runtime dependency on package providing libfoo
>
> ping
>
>>
>> Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
>> ---
>>   meta/classes/package.bbclass | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
>> index 96d7fd9..4685cd2 100644
>> --- a/meta/classes/package.bbclass
>> +++ b/meta/classes/package.bbclass
>> @@ -1572,7 +1572,7 @@ python package_do_shlibs() {
>>               # /opt/abc/lib/libfoo.so.1 and contains /usr/bin/abc depending on system library libfoo.so.1
>>               # but skipping it is still better alternative than providing own
>>               # version and then adding runtime dependency for the same system library
>> -            if private_libs and n in private_libs:
>> +            if private_libs and n[0] in private_libs:
>>                   bb.debug(2, '%s: Dependency %s covered by PRIVATE_LIBS' % (pkg, n[0]))
>>                   continue
>>               if n[0] in shlib_provider.keys():
>> --
>> 2.2.1
>>
>
>
>