On Tue, 2012-07-24 at 14:32 -0400, Yao Zhao wrote: > On 12-07-24 12:00 PM, Yao Zhao wrote: > > On 12-07-24 11:34 AM, Richard Purdie wrote: > >> On Tue, 2012-07-24 at 14:57 +0100, Burton, Ross wrote: > >>> On 24 July 2012 14:49, Yao Zhao <yao.z...@windriver.com> wrote: > >>>> when bzip2-native is installed in parallel to sysroot, it is > >>>> possible that > >>>> some packages are using bzip2 to unpack, there are chances that > >>>> bzip2 is > >>>> installed to sysroot but libbz2.so.0 not installed yet because > >>>> parallel > >>>> installation. > >>>> link bzip2 and bzip2recover statically to avoid this problem and > >>>> don't lose > >>>> parallel installation. libbz2.so is still available. > >>> Is it me, or is this officially getting silly? This probably happens > >>> for *every* binary in the sysroot that links to a library, which is > >>> probably a fair proportion of them. Statically linking every single > >>> one and then special-casing further problems where a static link isn't > >>> sufficient (see pythonnative) just isn't going to scale. > >> It happens for things in ASSUME_PROVIDED so there is only a finite list > >> of these issues. I'm curious what is actually triggering bzip2-native to > >> build given its in ASSUME_PROVIDED... > > Yeah, it is in the ASSUME_PROVIDED but somehow it was built too. I > > will take a further look at why it was built. > > > It seems that python-native is depending on "bzip2-full-native" and > bzip2 does provide this "bzip2-full-native". > Change it from "bzip2-full-native" to "bzip2-native" , bzip2-native is > not built any more. The code may not check the > Why we need the bzip2-full-native? any idea?
See my other reply but I think its libbz2 that it wants. Cheers, Richard _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
