[OE-core] Build failures due zlib problem

[Denys Dmytriyenko]

On Wed, Mar 21, 2012 at 09:53:59AM +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...

Actually, the original gzip, unlike pigz, does not link against zlib/libz. 
Same with tar, as Matthew was asking.

What about statically linking pigz against zlib?

-- 
Denys