[OE-core] [PATCH 0/5] shlibs providers improvements
Martin Jansa
martin.jansa at gmail.com
Sat Jan 18 14:02:05 UTC 2014
Fixes for [YOCTO #4628]
Richard had few more ideas to improve it even more, but this is good start.
Most important changes:
* PRIVATE_LIBS aren't duplicitly added to RDEPENDS (when recipe provides
own libfoo it shouldn't get runtime dependency on global libfoo shlib provider)
* warning is shown for undeterministic providers (multiple packages
recorded to provide the same library) - recipe maintainers can decide
if such library should be considered private or make sure that only one
package is built (most common case are gst plugins where 0.10 and 1.* provide
the same gst modules, but as long as nobody tries to linke directly to some
gst plugin we shouldn't list them as shlib providers).
* list files which require given shlib, often I was surprised to see that
something got runtime dependency on libfoo, showing which binary is linked to
it makes it easier to debug when you have only log.do_package and package
directory is already gone (e.g. analyzing test-dependencies.sh script outputs)
The following changes since commit 8163854adf87ac42a8f08ee25685d0ce1efb4724:
oe-selftest: separated the SStateBase and SStateTests in different modules (2014-01-16 12:18:44 +0000)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib jansa/shlib-providers
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=jansa/shlib-providers
Martin Jansa (5):
package.bbclass: move reading shlibs providers to separate function
package.bbclass: show warning when package is trying to provide
already provided shlib
package.bbclass: add SHLIBSSEARCHDIRS to define where to search for
shlib providers
package.bbclass: Don't search for prividers of PRIVATE_LIBS
package.bbclass: Show which files require given dependency in debug
output
meta/classes/package.bbclass | 102 +++++++++++++++++++++++++++++++------------
1 file changed, 75 insertions(+), 27 deletions(-)
--
1.8.5.2
More information about the Openembedded-core
mailing list