From 0cf128ca1b3b2c1c2d250842cd5f02c5f78eef24 Mon Sep 17 00:00:00 2001 From: Martin Jansa Date: Thu, 8 Jan 2015 18:11:18 +0100 Subject: [PATCH] package.bbclass: Fix support for private libs * n is a tuple since this commit: commit d3aa7668a9f001044d0a0f1ba2de425a36056102 Author: Richard Purdie 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 (From OE-Core rev: ec1d379683cedca4be1c252475d02c8041227142) (From OE-Core rev: c78a9246a1aae14a1598d4c801faaf27dd31f66a) Signed-off-by: Martin Jansa Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie --- 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 96d7fd9b26..4685cd2bc0 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():