12429 2017-12-17 16:52:30 +0000 Setting DEFAULTTUNE = "corei7-32" breaks building sdk 2018-10-20 14:46:34 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 2.3.2 x86 Multiple RESOLVED WORKSFORME Low normal 4.99 1 ferry.toth richard.purdie ferry.toth poky.bs.watcher poky.watcher richard.purdie --- --- No (bug/feature does not impact docs) oldest_to_newest 78719 0 ferry.toth 2017-12-17 16:52:30 +0000 I have: include conf/machine/include/tune-corei7.inc DEFAULTTUNE = "corei7-32" (this is to build the Intel Edison which has corei7 instruction set, but SOC optimized for 32 bits) With 2.3.2 (pyro) this builds my kernel and system image fine. However after building the sdk under /opt/poky-edison/2.3.2/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux/ I have: x86_64-poky-linux-addr2line x86_64-poky-linux-c++filt x86_64-poky-linux-elfedit x86_64-poky-linux-gcc-ar x86_64-poky-linux-gcov x86_64-poky-linux-gprof x86_64-poky-linux-ld.gold x86_64-poky-linux-objdump x86_64-poky-linux-size x86_64-poky-linux-ar x86_64-poky-linux-cpp x86_64-poky-linux-g++ x86_64-poky-linux-gcc-nm x86_64-poky-linux-gcov-tool x86_64-poky-linux-ld x86_64-poky-linux-nm x86_64-poky-linux-ranlib x86_64-poky-linux-strings x86_64-poky-linux-as x86_64-poky-linux-dwp x86_64-poky-linux-gcc x86_64-poky-linux-gcc-ranlib x86_64-poky-linux-gdb x86_64-poky-linux-ld.bfd x86_64-poky-linux-objcopy x86_64-poky-linux-readelf x86_64-poky-linux-strip And the generate environment-setup-corei7-32-poky-linux has: export CC="i686-poky-linux-gcc -m32 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mstackrealign --sysroot=$SDKTARGETSYSROOT" export CXX="i686-poky-linux-g++ -m32 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mstackrealign --sysroot=$SDKTARGETSYSROOT" As a result the sdk is just not working. 78720 1 ferry.toth 2017-12-17 16:56:35 +0000 And strangely, doing the opposite: include conf/machine/include/tune-core2.inc DEFAULTTUNE = "core2-64" Builds the sdk just fine. 78751 2 richard.purdie 2017-12-19 15:40:23 +0000 I tried tweaking qemux86-64 to this config and the SDK was fine with master. I'll try and check pyro buts its possible this fixed in subsequent changes since pyro. 78754 3 richard.purdie 2017-12-19 16:15:00 +0000 Adding this: diff --git a/meta/conf/machine/qemux86-64.conf b/meta/conf/machine/qemux86-64.conf index 10189cb5c3e..5f271cf3371 100644 --- a/meta/conf/machine/qemux86-64.conf +++ b/meta/conf/machine/qemux86-64.conf @@ -9,8 +9,10 @@ PREFERRED_PROVIDER_virtual/libgles2 ?= "mesa" require conf/machine/include/qemu.inc DEFAULTTUNE ?= "core2-64" -require conf/machine/include/tune-core2.inc require conf/machine/include/qemuboot-x86.inc +DEFAULTTUNE = "corei7-32" +require conf/machine/include/tune-corei7.inc then MACHINE=qemux86-64 bitbake core-image-sato -c populate_sdk then adding INHERIT += "testimage" to local.conf and: MACHINE=qemux86-64 bitbake core-image-sato -c testsdk reports that the toolchain builds and works just fine. I did this on pyro. I looked into the sdk and the compiler is all prefixed with i686 so the environment file works just fine, unlike yours. I'm going to need help to reproduce this. 78755 4 ferry.toth 2017-12-19 16:20:24 +0000 Alright, what do you need. I have my stuff here: https://github.com/htot/meta-intel-edison/tree/pyro64 This builds the image for a 64b target, on a 64b host and works fine. 78756 5 ferry.toth 2017-12-19 16:22:19 +0000 Eh, the file you are looking for is probably here: https://github.com/htot/meta-intel-edison/blob/pyro64/meta-intel-edison-bsp/conf/machine/edison.conf 78926 6 sjolley.yp.pm 2018-01-05 16:35:42 +0000 Richard, It appears that your question has been answered. If you still have a question please restate and put it back in NEEDINFO. 81916 7 richard.purdie 2018-10-18 22:19:40 +0000 I tried again and the toolchain works for me as described. If you still have problems, please provide a patch against OE-Core which reproduces the problem. The link you provided is for a core2-64 configuration whilst the bug you're talking about is for a corei7-32 one so something is confused. 81921 8 ferry.toth 2018-10-19 07:50:19 +0000 I need to retry this. It may be caused by me not using the sdk as intended, i.e. I am not installing the sdk after building but instead put a link in /opt to the generated sdk. This work fine, but it may be that you can only do this once, i.e. build an i686 sdk works, then switch to x86_64 and build x86_64 sdk then paths are wrong and will not work by just having a a link in /opt. 81929 9 ferry.toth 2018-10-20 14:46:34 +0000 Ok, I just rebuilt. Current we are on sumo. Using the branch sumo32 we build on x86_64 for edison corei7-32. Git repo with machine conf is here: https://github.com/edison-fw/meta-intel-edison/blob/sumo32/meta-intel-edison-bsp/conf/machine/edison.conf I apply for this build: -include conf/machine/include/tune-core2.inc +include conf/machine/include/tune-corei7.inc TUNE_CCARGS .= " -mstackrealign" -#DEFAULTTUNE = "core2-64" +DEFAULTTUNE = "corei7-32" Now I have under sdk/2.5.1/sysroots/x86_64-pokysdk-linux/usr/bin/i686-poky-linux/ gcc tools with prefix i686-poky-linux. And the environment script sets up the correct gcc: $ which $CC /opt/poky-edison/2.5.1/sysroots/x86_64-pokysdk-linux/usr/bin/i686-poky-linux/i686-poky-linux-gcc So this issue seems to be fix at least in sumo and maybe earlier. One question remains: why is gcc called i686-poky-linux-gcc? # gcc -v shows (among other flags) --build=x86_64-linux --host=x86_64-pokysdk-linux --target=i686-poky-linux Why not corei7?