Re: [Angstrom-devel] [OE-core] gcc-cross-initial Failure (is a meta-aarch64 screw up)
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 m...@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 m...@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 (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- log.do_compile.25230___ Openembedded-core mailing list openembedded-c...@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] [OE-core] gcc-cross-initial Failure (is a meta-aarch64 screw up)
Op 8 mei 2013, om 04:23 heeft Khem Raj raj.k...@gmail.com het volgende geschreven: 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. Yes, please disable it till meta-aarch86 gets fixed regards, Koen Thanks On Apr 8, 2013, at 2:06 AM, Jack Mitchell m...@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 m...@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 (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- log.do_compile.25230___ Openembedded-core mailing list openembedded-c...@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
