From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [12.173.51.132] (helo=emailgateway.hillcrestlabs.com) by linuxtogo.org with esmtp (Exim 4.69) (envelope-from ) id 1MdTit-0004cs-P0 for openembedded-devel@lists.openembedded.org; Tue, 18 Aug 2009 20:47:55 +0200 X-AuditID: 0a1e000a-b7ba8ae000000dd5-64-4a8af358d047 From: Chris Conroy To: openembedded-devel@lists.openembedded.org In-Reply-To: <20090818174157.GB25000@denix.org> References: <1250176750.29049.1003.camel@conroy-linux> <20090813155909.GC8906@gmail.com> <1250612879.6785.12.camel@conroy-linux> <20090818174157.GB25000@denix.org> Date: Tue, 18 Aug 2009 14:30:12 -0400 Message-Id: <1250620212.6785.43.camel@conroy-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 X-Brightmail-Tracker: AAAAAA== Subject: Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes X-BeenThere: openembedded-devel@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: openembedded-devel@lists.openembedded.org List-Id: Using the OpenEmbedded metadata to build Distributions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 18:47:56 -0000 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sorry for not providing more detail at first... With debian renaming on, glibc, for example, gets renamed to 'libc6' and packaged as such. Normally, this works because the other packages pick up the rename at some point along the way. The comment at the top of debian.bbclass states: # Debian package renaming only occurs when a package is built # We therefore have to make sure we build all runtime packages # before building the current package to make the packages runtime # depends are correct So, glibc is packaged as part of my toolchain's sdk. Building meta-toolchain works just fine. Then, I go to build an image using the external-toolchain. It fails because opkg cannot satisfy the dependency for 'glibc (>=2.7)'. This is because the ipkg generated by the debian rename is named 'libc6_2.7-r9_mipsel.ipk'. During the creation of the toolchain, all packages picked up this rename. Since glibc does not get rebuilt when *using* the external toolchain (that's sort of the whole point), the debian rename does not occur, and we have this name mismatch. This same issue occurs for the other libs in my sdk including libstdc++, libgcc, etc.. The error went away for me after I turned off Debian Renaming. On Tue, 2009-08-18 at 13:41 -0400, Denys Dmytriyenko wrote: > On Tue, Aug 18, 2009 at 12:27:59PM -0400, Chris Conroy wrote: > > However, I've run in to a different problem. It seems that Debian > > Renaming does not play nicely with the external toolchain. Digging into > > the code, it seems that Debian renaming relies on the package being in > > the workdir to do its magic, which for any prebuilt SDK packages will > > not hold true. Any thoughts on the proper route to fix this aside from > > just turning of Debian Renaming? > > Can you please provide more details on the problem? Thanks. >