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

[Denys Dmytriyenko <denis@denix.org>]

On Tue, Aug 18, 2009 at 10:32:42PM +0100, Phil Blundell wrote:
> On Tue, 2009-08-18 at 14:25 -0700, Khem Raj wrote:
> > 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.
> 
> I think that, for most folks, avoiding the epic glibc build process is
> probably one of the main attractions of an external toolchain.
> 
> In any case, building glibc from source wouldn't actually remove this
> problem since you would then just have the same trouble with libgcc,
> libobjc and suchlike.

Those libraries and their pkgdata have to be provided in the ipk/, pkgdata/ 
and shlibs/ directories of an external toolchain. The external-toolchain.bb 
recipe itself then copies them into the deploy directory and they are then 
used during the image generation process. I've been using it for quite some 
time and see no problems with debian naming, i.e. glibc vs. libc6. Check 
do_stage of external-toolchain.bb to see what it expects.

Please note, that meta-toolchain.bb by default produces an SDK, which can be 
used outside of OE for cross-compiling. It can also be used inside OE for 
compilation by using external-toolchain.bb, but the step which packages ipks 
and pkgdata for libc and libgcc to be installed into the filesystem, is 
missing from the meta-toolchain.bb...

BTW, I'm using external-toolchain.bb in my project for prebuilt binary 
toolchains, like CodeSourcery Lite or old MontaVista Pro. I have their 
libraries packaged into ipks for rootfs to work. One way is to extend 
external-toolchain.bb recipe to do the packaging...

-- 
Denys