From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 93-97-173-237.zone5.bethere.co.uk ([93.97.173.237] helo=tim.rpsys.net) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1SAINo-0007si-Pp for openembedded-core@lists.openembedded.org; Wed, 21 Mar 2012 11:03:09 +0100 Received: from localhost (localhost [127.0.0.1]) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id q2L9sCYJ032763 for ; Wed, 21 Mar 2012 09:54:12 GMT Received: from tim.rpsys.net ([127.0.0.1]) by localhost (tim.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32590-02 for ; Wed, 21 Mar 2012 09:54:07 +0000 (GMT) Received: from [192.168.3.10] ([192.168.3.10]) (authenticated bits=0) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id q2L9rwrP032757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Mar 2012 09:54:05 GMT Message-ID: <1332323639.9740.125.camel@ted> From: Richard Purdie To: Patches and discussions about the oe-core layer Date: Wed, 21 Mar 2012 09:53:59 +0000 In-Reply-To: References: X-Mailer: Evolution 3.2.2- Mime-Version: 1.0 X-Virus-Scanned: amavisd-new at rpsys.net Subject: Re: Build failures due zlib problem X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 10:03:09 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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