Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Chris Conroy <Chris.Conroy@hillcrestlabs.com>]

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