On Fri, 2013-06-07 at 21:20 +0200, Martin Jansa wrote: > Imagine this process > > foo.bb DEPENDS on libabc.bb to provide libabc.1.so > > evil recipe bar.bb installs some binary crap in /opt/crap and because it's > picky about libabc version it bundles own compy of libabc.so.1 and > installs it to /opt/crap/lib/libabc.so.1 > > At the time of first build nobody notices libabc.1.so and foo, bar and > libabc are happily populated to sysroot. > > foo.bb is rebuilt because of some unrelated change, but this times it > uses bar as shlibs provider for libabc.so.1
It sounds like the real bug here is that the shlibdeps code doesn't issue a diagnostic when it encounters this kind of ambiguous situation. It ought to be perfectly capable of figuring out that there are two copies of libabc.so.1 at large which belong to different packages and, absent additional guidance, it has no reliable way of knowing which one of those is going to satisfy the DT_NEEDED in any random binary. If shlibdeps stopped with an error in that situation, which arguably it ought to, then the erroneous dependency would never get into sstate and the scenario that you describe would not be able to happen. p. _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
