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 1QrXIg-0001c7-DO for openembedded-core@lists.openembedded.org; Thu, 11 Aug 2011 17:36:02 +0200 Received: from localhost (localhost [127.0.0.1]) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id p7BFVSbI031887; Thu, 11 Aug 2011 16:31:28 +0100 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 31583-04; Thu, 11 Aug 2011 16:31:24 +0100 (BST) 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 p7BFVJ2k031881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Aug 2011 16:31:20 +0100 From: Richard Purdie To: Patches and discussions about the oe-core layer In-Reply-To: <1D98D492-1D74-49DE-A884-C919AFF30BDD@kernel.crashing.org> References: <1312484099-29314-1-git-send-email-galak@kernel.crashing.org> <4E437883.90406@intel.com> <1D98D492-1D74-49DE-A884-C919AFF30BDD@kernel.crashing.org> Date: Thu, 11 Aug 2011 16:30:41 +0100 Message-ID: <1313076641.14274.431.camel@rex> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 X-Virus-Scanned: amavisd-new at rpsys.net Subject: Re: [PATCH] gcc: use ${base_lib} to match gcc default configuration 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: Thu, 11 Aug 2011 15:36:02 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2011-08-11 at 01:47 -0500, Kumar Gala wrote: > revert this is not acceptable as that will break ppc64 builds. > > I think you need to look at 64bithack.patch and if we really should be using it for multilib builds. This just sounds like gcc totally ignores the the library directory we're using and that is plain wrong :(. I'd much prefer gcc didn't make assumptions in this case and did what were were configuring it to do. That is why there is that 64bit hack there and I think gcc should be honouring however we configure the library directories, not doing what it thinks is best... Cheers, Richard