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

Khem Raj raj.khem at gmail.com
Thu Aug 13 15:59:09 UTC 2009


On (13/08/09 11:19), Chris Conroy wrote:
> I've spent a pretty good chunk of time this past week trying to get a
> working external toolchain, but I've hit a bit of a wall and can't
> figure out how to fix this last problem.
> 
> I'm trying to build a gcc-cross-sdk with GCC 4.2.3, and for a while I
> faced a chicken-and-egg problem of finding limits.h where the creation
> of the cross-sdk would succeed only if the eventual install location
> (in /usr/local/path/to/toolchain/ existed). By pulling in the
> sdk-libstdc++-includes.patch from poky, I was able to remove this issue
> during the creation of gcc-cross-sdk.
> 
> Now, chicken and egg fixed (properly?) using the external toolchain
> results in cross packages failing to find limits.h (specifically, the
> #include_next<limits.h> in ${prefix}/usr/include/limits.h. It's unclear
> to me which (if any) limits.h should be installed (and where).

limits.h should come from glibc. which should include the one provided
by gcc in include-fixed gcc-cross-sdk should have done that.
Deleting include_next is not the correct thing to do.
> 
> I've run through the gcc-cross-sdk work directory and was unable to find
> any obvious choices (all of the copies there also asked for an
> include_next).
> 
> If I make the assumption that this is just an erroneous include_next, I
> can successfully compile and run some packages. However, I cannot build
> the kernel because it fails on the assembly inside asm_offsets.c. This
> leads me to believe that removing that include_next was not a valid fix
> (no surprise there), and perhaps fixing this limits.h issue properly
> will be the last step in creating a working external toolchain. I don't
> see any obvious choices within gcc, but perhaps I need to pull from
> glibc, glibc-initial, or perhaps a particular host file?
> 
> Note that this is NOT GCC 4.3.x which moved the fixincludes directory
> and made some issues with finding limits.h. Most of the references I've
> found to this bug indicate that people had this working before upgrading
> to 4.3.x, and therefore I'm a bit surprised to be running into a similar
> issue with 4.2.x
> 
> (For reference, this is with glibc 2.7 and binutils 2.19 for a
> mipsel-linux target building on an x86_64 host)
> 
> --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