Hello Chris, Probably unrelated, but yesterday my krogoth build failed on an Atom *host/build* system. I was just about to debug this when I saw your email.
The configure stage of gmp-native decided to choose -march=k8 and -mtune=k8 -m64. I am debugging this currently. Maybe check if the asterix recipe tries to be smart in a similar way? And verify the do_compile log for actual compiler options. Regards, Leon. build/tmp-glibc/work/x86_64-linux/gmp-native/6.1.0-r0 configure: checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64 ... yes checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8... yes checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8... yes "-m64 -mtune=k8 -march=k8" on gcc 5.4.0: x86_64-linux-libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../gmp-6.1.0/cxx -I.. -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0 -isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 -isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe -c ../../gmp-6.1.0/cxx/osmpq.cc -fPIC -DPIC -o .libs/osmpq.o ../x86_64-linux-libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../gmp-6.1.0/cxx -I.. -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0 -isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 -isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe -c -o osmpz.lo ../../gmp-6.1.0/cxx/osmpz.cc make[2]: *** [osmpz.lo] Segmentation fault On Mon, Jan 16, 2017 at 9:46 AM, Chris Trobridge <christrobri...@hotmail.com > wrote: > This arose building asterisk switching from 13.7 to 13.11+. > > > The executable core dumps immediately with an illegal instruction > instruction, which gdb reported as 'andn'. This is part of BMI1, which > was introduced with Haswell. I am targeting a (32-bit) Z5xx Atom > processor, which predates this instruction. > > > I don't know what changed in the Asterisk build to cause this (the > instruction is in some regular compiler generate code) but the compiler is > still generating legal core2 code and tune-core2.inc is recommended for > Atom processors: > > > "This tune is recommended for the Intel Core 2 CPU family, including > Conroe, Merom and beyond, as well as the first Atom CPUs, Diamondville, > and beyond." > > > I am still considering this output is down to some quirk in my > configuration but I found that -mtune and -march options were added for > Atom in GCC in 4.5, so this could be another line of attack, although I > didn't find any explicit code for this in meta/meta-intel. > > > Any ideas? > > > My initial plan is to try to acoid the core2 tuning and then, if that > helps, attempt to get atom tuning working, unless that's likely to be cause > further breakages due to being unexpected. > > > Regards, > > Chris > > > > > -- > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto