[oe] gcc-cross-sdk (GCC 4.2.3) limits.h woes

Khem Raj raj.khem at gmail.com
Tue Aug 18 21:25:08 UTC 2009


On Tue, Aug 18, 2009 at 1:10 PM, Chris
Conroy<Chris.Conroy at hillcrestlabs.com> wrote:
> On Tue, 2009-08-18 at 12:50 -0700, Tom Rini wrote:
>>
>> OK, here's the problem, I think.  You're trying to make an image for say
>> i686-armv6-sdk-linux-gnueabi?  What are you expecting to be in this raw
>> image however, the contents of say meta-toolchain, extracted and put
>> into a ext2?  For most people, meta-toolchain, and the resulting tarball
>> are the output that gets used.
>>
>
> The problem is the dependencies get satisfied during the build because
> package X depends on glibc, but external-toolchain.bb chimes in and says
> "Hi, I provide virtual/libc." Package X builds and links just fine since
> the external-toolchain dropped everything in the right place.
>
> The problem comes whenever opkg needs to deal with dependencies since it
> doesn't know about 'virtual/libc'. It sees that Package X wants glibc
> and it can't find it since it only knows about the debian-named version
> called 'libc6'. Glibc never gets built (since it's already been built)
> and thus never gets debian renamed.
>
> I don't see any easy path to change debian.bbclass since it requires
> introspection on the TMPDIR which does not exist for users of an
> external toolchain.
>
> I hope this is clear. Let me know if there are any points of confusion.
>
> In the meantime, turning off the renaming successfully works around this
> bug.

Do you have to use glibc built externally ? I would think that use
external compiler
and tools but build everything else that goes on target which is also libc.

>
> --Chris Conroy
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>




More information about the Openembedded-devel mailing list