On Wed, 2012-03-21 at 09:53 +0000, Richard Purdie wrote: > On Tue, 2012-03-20 at 22:40 -0300, Otavio Salvador wrote: > > | NOTE: Unpacking > > /home/ostt-devel/src/embedded-systems/downloads/gcc-4_6-branch_gcc.gnu.org_.svn.gcc.branches_184847_.tar.gz > > to > > /home/ostt-devel/src/embedded-systems/tmp-eglibc-eglibc/work-shared/gcc-4.6.3+svnr184847-r28/ > > | gzip: /usr/lib/libz.so.1: version `ZLIB_1.2.5.1' not found (required by > > gzip) > > | tar: Child returned status 1 > > > > Does anyone sees it? Our autobuilder is failing this way. > > Yes, its being seen. I think its appeared after the pigz-native change > but it exposes an underlying problem. > > The issue is that we have a gzip binary in the sysroot linking against > libz. We can get into a situation where we remove libz to rebuild but we > don't remove the gzip binary yet. > > gzip-native is a tricky one since its one of those recipes we don't > correctly have a dependency chain for and is also implied in > ASSUME_PROVIDED (else how to we extract tarballs?). > > Whilst I've implicated pigz-native, we could potentially see this with > gzip-native too, I'd guess its just more flexible about the libz symbols > it uses. > > I'm trying to come up with a good way of handling this but at the moment > I'm drawing a blank for a neat solution :(. > > Something along the lines of perl-native might be necessary. We could > also decide its a special case and remove gzip whenever libz is > removed...
I've pushed a couple of fixes in this area which should help. Cheers, Richard _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core