Build failures due zlib problem

Build failures due zlib problem

[Otavio Salvador]

| 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.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Build failures due zlib problem

[Richard Purdie]

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...

Cheers,

Richard

Re: Build failures due zlib problem

[Richard Purdie]

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

Re: Build failures due zlib problem

[McClintock Matthew-B29882]

On Wed, Mar 21, 2012 at 4:53 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> 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 seen your fix and it seems reasonable - but doesn't 'tar' have
the same issue?

-M

Re: 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

Re: Build failures due zlib problem

[Richard Purdie]

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

Re: Build failures due zlib problem

[Otavio Salvador]

On Wed, Mar 21, 2012 at 13:55, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> I've pushed a couple of fixes in this area which should help.

It fixed my issues.

Thanks a lot.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br