[OE-core] gcc-cross-initial Failure (is a meta-aarch64 screw up)

[Khem Raj]

Hi Jack

since I was playing with archlinux today, I could reproduce this gcc ICE problem with angstrom. Actual issue has been already fixed with

http://git.openembedded.org/openembedded-core/commit/?id=b1dc91969f9bb0c2a3a4336f5e9a2f57aabb9f78

but it was still failing on angstrom/cortex-a8-hf and it took some time to realize that angstrom is including meta-aarch64 layer and
it has totally totally screwed up the toolchain build since this layer forked the .inc files from oe-core gcc at some point and never did kept them
in sync with OE-Core it meant that even when I wanted to use gcc 4.7 from OE-Core it was picking .incs from meta-aarch64 and the patch
which was applied to OE-Core recently has been ignored and hence the gcc ICE

meta-aarch64 has

$ find . -name *.inc
./recipes-devtools/binutils/binutils-cross-canadian.inc
./recipes-devtools/binutils/binutils-git.inc
./recipes-devtools/binutils/binutils-cross.inc
./recipes-devtools/binutils/binutils.inc
./recipes-devtools/gcc/gcc-crosssdk-initial.inc
./recipes-devtools/gcc/gcc-common.inc
./recipes-devtools/gcc/gcc-configure-common.inc
./recipes-devtools/gcc/gcc-cross4.inc
./recipes-devtools/gcc/gcc-cross-canadian.inc
./recipes-devtools/gcc/gcc-cross-initial.inc
./recipes-devtools/gcc/gcc-package-sdk.inc
./recipes-devtools/gcc/gcc-package-runtime.inc
./recipes-devtools/gcc/gcc-package-target.inc
./recipes-devtools/gcc/gcc-crosssdk.inc
./recipes-devtools/gcc/gcc-4.7.inc
./recipes-devtools/gcc/gcc-configure-sdk.inc
./recipes-devtools/gcc/gcc-configure-runtime.inc
./recipes-devtools/gcc/gcc-configure-cross.inc
./recipes-devtools/gcc/gcc-package-cross.inc
./recipes-devtools/gcc/gcc-cross.inc
./recipes-devtools/gcc/gcc-configure-target.inc
./recipes-devtools/gdb/gdb-cross.inc
./recipes-devtools/gdb/gdb.inc
./recipes-devtools/gdb/gdb-common.inc


This seems totally wrong to me to since it overrides recipes in subtle ways and does not document it anywhere

firstly, README is not there and as it seems its a BSP layer but it has much more than a BSP metadata in it.
even then if it needed a new toolchain then it should have used different names for includes like meta-linaro-toolchain does.

if it needed to enhance existing recipes from OE-Core or reuse them then it should have included them as it is and tweaked with bbappend
or created new recipes itself for aarch64 compiler tools.

I will leave this to meta-linaro devs to sort out and let it play better with rest of layers meanwhile I will propose to disable meta-aarch64 in angstrom. 

Thanks

On Apr 8, 2013, at 2:06 AM, Jack Mitchell <ml at communistcode.co.uk> wrote:

> On 08/04/13 09:52, Jack Mitchell wrote:
>> On 05/04/13 18:03, Khem Raj wrote:
>>> On Apr 5, 2013, at 9:36 AM, Jack Mitchell <ml at communistcode.co.uk> wrote:
>>> 
>>>> I build for the beaglebone and I changed them in line with your default beaglebone build patch you posted a week or so ago. I think it moved it form soft to hard float possibly...
>>> yes do a clean build if possible
>> 
>> Hi Khem,
>> 
>> Clean build results in the same failure.
>> 
>> Host GCC:
>> 
>> Using built-in specs.
>> COLLECT_GCC=gcc
>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper 
>> Target: x86_64-unknown-linux-gnu
>> Configured with: /build/src/gcc-4.8.0/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-install-libiberty --disable-multilib --disable-libssp --disable-werror --enable-checking=release
>> Thread model: posix
>> gcc version 4.8.0 (GCC)
>> 
>> 
>> Tune:
>> 
>> DEFAULTTUNE_beaglebone = "cortexa8hf-neon"
>> 
>> Cheers,
>> 
> 
> Ok, looks like it might have been fluke that it just failed when I changed tune, as it also fails with the old tune, please see attached.
> 
> Cheers,
> Jack.
> 
> -- 
> 
>  Jack Mitchell (jack at embed.me.uk)
>  Embedded Systems Engineer
>  http://www.embed.me.uk
> 
> --
> 
> <log.do_compile.25230>_______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core