Re: Build failures due zlib problem

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2012-03-21 at 15:53 -0400, Denys Dmytriyenko wrote:
> 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?

The trouble here isn't just about linking. Its about execution of a
binary that might be half copied for example. We don't currently
atomically deal with files under sstate control, we assume users would
only use them when dependencies are met. I'm not sure we should ever
want to use something that is potentially being copied or could go away.
tar is special in that regard because of how and when we build it.

Cheers,

Richard