* Re: Build failures due zlib problem
2012-03-21 9:53 ` Richard Purdie
@ 2012-03-21 16:55 ` Richard Purdie
2012-03-22 17:12 ` Otavio Salvador
2012-03-21 17:50 ` McClintock Matthew-B29882
2012-03-21 19:53 ` Denys Dmytriyenko
2 siblings, 1 reply; 7+ messages in thread
From: Richard Purdie @ 2012-03-21 16:55 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Build failures due zlib problem
2012-03-21 9:53 ` Richard Purdie
2012-03-21 16:55 ` Richard Purdie
@ 2012-03-21 17:50 ` McClintock Matthew-B29882
2012-03-21 19:53 ` Denys Dmytriyenko
2 siblings, 0 replies; 7+ messages in thread
From: McClintock Matthew-B29882 @ 2012-03-21 17:50 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Build failures due zlib problem
2012-03-21 9:53 ` Richard Purdie
2012-03-21 16:55 ` Richard Purdie
2012-03-21 17:50 ` McClintock Matthew-B29882
@ 2012-03-21 19:53 ` Denys Dmytriyenko
2012-03-21 22:40 ` Richard Purdie
2 siblings, 1 reply; 7+ messages in thread
From: Denys Dmytriyenko @ 2012-03-21 19:53 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Build failures due zlib problem
2012-03-21 19:53 ` Denys Dmytriyenko
@ 2012-03-21 22:40 ` Richard Purdie
0 siblings, 0 replies; 7+ messages in thread
From: Richard Purdie @ 2012-03-21 22:40 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 7+ messages in thread