When building v2017.03-rc1 or later with an SDK from say qemux86-64 and core-image-minimal the build will fail with: LDFLAGS="" python \ ./lib/libfdt/setup.py "-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DCONFIG_FIT_SIGNATURE -include ./include/libfdt_env.h -idirafterinclude -idirafter./arch/arm/include -I./lib/libfdt -I./tools -DCONFIG_SYS_TEXT_BASE=0x4000000 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE " lib/libfdt/fdt.c lib/libfdt/fdt_ro.c lib/libfdt/fdt_rw.c lib/libfdt/fdt_strerror.c lib/libfdt/fdt_wip.c lib/libfdt/fdt_region.c lib/libfdt/fdt_sw.c tools/libfdt_wrap.c unable to execute 'x86_64-oesdk-linux-gcc': No such file or directory error: command 'x86_64-oesdk-linux-gcc' failed with exit status 1 tools/Makefile:123: recipe for target 'tools/_libfdt.so' failed make[1]: *** [tools/_libfdt.so] Error 1 Makefile:1229: recipe for target 'tools' failed make: *** [tools] Error 2 This is because U-Boot needs to build something for python later on with 'python ..../setup.py' and in turn fails as above. That is because we end up using python from the SDK and that wants to use the x86_64-oesdk-linux-gcc which is not shipped so fails.
Tom, can you please provide detailed steps so I can reproduce the problem? Thanks
I found the original problem trying to build u-boot for a zynq board. Let me know if you need more details to reproduce the problem. Build an sdk with: bitbake -c populate_sdk core-image-minimal Install the sdk. Source the environment file. [balister@thuvia u-boot (master)]$ . ~/sdks/oe-master/environment-setup-armv7ahf-neon-oe-linux-gnueabi Checkout u-boot/master git clone git://git.denx.de/u-boot.git $ cd u-boot $ make zynq_zc702_defconfig $ make Leads to a build failure: HOSTLD tools/fit_info HOSTLD tools/fit_check_sign LDFLAGS="" python ./lib/libfdt/setup.py \ "-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -DCONFIG_FIT_SIGNATURE -include ./include/libfdt_env.h -idirafterinclude -idirafter./arch/arm/include -I./lib/libfdt -I./tools -DCONFIG_SYS_TEXT_BASE=0x4000000 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -D_GNU_SOURCE " lib/libfdt/fdt.c lib/libfdt/fdt_ro.c lib/libfdt/fdt_rw.c lib/libfdt/fdt_strerror.c lib/libfdt/fdt_wip.c lib/libfdt/fdt_region.c lib/libfdt/fdt_sw.c tools/libfdt_wrap.c unable to execute 'x86_64-oesdk-linux-gcc': No such file or directory error: command 'x86_64-oesdk-linux-gcc' failed with exit status 1 tools/Makefile:123: recipe for target 'tools/_libfdt.so' failed make[1]: *** [tools/_libfdt.so] Error 1 Makefile:1229: recipe for target 'tools' failed make: *** [tools] Error 2
Please also provide settings in your local.conf (MACHINE etc.) (In reply to comment #2) > I found the original problem trying to build u-boot for a zynq board. Let me > know if you need more details to reproduce the problem. > > Build an sdk with: > > bitbake -c populate_sdk core-image-minimal > > Install the sdk. > > Source the environment file. > > [balister@thuvia u-boot (master)]$ . > ~/sdks/oe-master/environment-setup-armv7ahf-neon-oe-linux-gnueabi > > Checkout u-boot/master > > git clone git://git.denx.de/u-boot.git > > $ cd u-boot > $ make zynq_zc702_defconfig > $ make > > Leads to a build failure: > > HOSTLD tools/fit_info > HOSTLD tools/fit_check_sign > LDFLAGS="" python ./lib/libfdt/setup.py \ > "-Wall -Wstrict-prototypes -O2 -fomit-frame-pointer > -DCONFIG_FIT_SIGNATURE -include ./include/libfdt_env.h -idirafterinclude > -idirafter./arch/arm/include -I./lib/libfdt -I./tools > -DCONFIG_SYS_TEXT_BASE=0x4000000 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES > -D_GNU_SOURCE " lib/libfdt/fdt.c lib/libfdt/fdt_ro.c lib/libfdt/fdt_rw.c > lib/libfdt/fdt_strerror.c lib/libfdt/fdt_wip.c lib/libfdt/fdt_region.c > lib/libfdt/fdt_sw.c tools/libfdt_wrap.c > unable to execute 'x86_64-oesdk-linux-gcc': No such file or directory > error: command 'x86_64-oesdk-linux-gcc' failed with exit status 1 > tools/Makefile:123: recipe for target 'tools/_libfdt.so' failed > make[1]: *** [tools/_libfdt.so] Error 1 > Makefile:1229: recipe for target 'tools' failed > make: *** [tools] Error 2 Hmmm...still cannot reproduce (Although I do get some errors regarding some missing header files) Please provide settings in your local.conf (MACHINE, TUNE etc...) There seems to be some inconsistency. Best upload the whole file. Also can you please run more verbose, i.e: $ make V=1
MACHINE qemuarm should work. What machine did you build the sdk for?
(In reply to comment #4) > MACHINE qemuarm should work. What machine did you build the sdk for? I have MACHINE="qemuarm" $ bitbake core-image-minimal -c populate_sdk Install SDK into ~/sdk-11062-arm, then $ mkdir ~/bug-11062 $ cd ~/bug-11062 $ git clone git://git.denx.de/u-boot.git $ cd u-boot $ source ~/sdk-11062-arm/environment-setup-armv5e-poky-linux-gnueabi $ make zynq_zc702_defconfig $ make And got: ... HOSTCC tools/mkenvimage.o HOSTCC tools/os_support.o HOSTLD tools/mkenvimage HOSTCC tools/aisimage.o In file included from tools/aisimage.c:10:0: include/image.h:1024:27: fatal error: openssl/evp.h: No such file or directory compilation terminated. make[1]: *** [scripts/Makefile.host:116: tools/aisimage.o] Error 1 make: *** [Makefile:1229: tools] Error 2 At this point, there is no cross-compiler involved, the host C-compiler was used. Also, I built the SDK using a very recent yocto master.
I'm guessing you need openssl-dev on the build machine? Must need to leak from host :)
Created attachment 3640 [details] console output - build log
(In reply to comment #6) > I'm guessing you need openssl-dev on the build machine? Must need to leak > from host :) OK, so I installed: $ sudo apt-get install libssl-dev followed by $ make and got a clean build with u-boot. (attached to console output)
OK, I think I see what is going on. I suspect I used an image recipe that adds python to the sdk, because my sdk needs to do things like mako. I'm guessing the core-image-minimal doesn't include python. Let me try adding python to the sdk via an entry in local.conf so we can document the problem. If a core-image-minimal doesn't have python, I'm happy to reduce importance of this. There is also a work around using host python by un-setting some vars fro the environment script. Still, a bit worrying if you ask the sdk python what c compiler was used to build it, it returns a non-existent compiler.
So, one thing that can be more easily documented / understood here about the problem is that the python SDK ends up run-time-requiring the OE-produced gcc & company but doesn't force it to be installed.
(In reply to comment #9) > OK, I think I see what is going on. I suspect I used an image recipe that > adds python to the sdk, because my sdk needs to do things like mako. I'm > guessing the core-image-minimal doesn't include python. > > Let me try adding python to the sdk via an entry in local.conf so we can > document the problem. > > If a core-image-minimal doesn't have python, I'm happy to reduce importance > of this. There is also a work around using host python by un-setting some > vars fro the environment script. > > Still, a bit worrying if you ask the sdk python what c compiler was used to > build it, it returns a non-existent compiler. Well, I still don't understand what is actually the problem here. Both python & python3 ARE installed in the SDK, once you source the environment and type $ which python should give you the one from the SDK. The SDK itself contains cross-compilers, but not the host compilers. U-boot needed to build something (libfdt) using the host compiler, so the C compiler from the host was used. (in my case the one that came with Ubuntu)
Can you try "x86_64-oesdk-linux-gcc"? This is the compiler u-boot is trying to use during the build process.
(In reply to comment #12) > Can you try "x86_64-oesdk-linux-gcc"? This is the compiler u-boot is trying > to use during the build process. I cannot try it as I don't have it. It seems to be something picked-up from the environment. grepping u-boot tree did not show x86_64-oesdk-linux-gcc either.
Naturally the vendor name will be different if you are using poky, i.e. x86_64-pokysdk-linux-gcc.
Paul, good point. I meant to write "which ...-gcc" to see if you had the cmpiler used to build python somewhere else in your path.
I believe the NEEDINFO has been answered. If that is not the case, please ask the question again and assign this to the owner needing to answer the question.
Can you please provide EXACT steps to reproduce the problem, including your build environment? The more information the better. Following the steps you described I could not reproduce the problem. So there is some vital piece of information missing. To summarize, I followed your steps and did this: I have MACHINE="qemuarm" I needed to install: $ sudo apt-get install libssl-dev $ bitbake core-image-minimal -c populate_sdk Install SDK into ~/sdk-11062-arm, then $ mkdir ~/bug-11062 $ cd ~/bug-11062 $ git clone git://git.denx.de/u-boot.git $ cd u-boot $ source ~/sdk-11062-arm/environment-setup-armv5e-poky-linux-gnueabi $ make zynq_zc702_defconfig $ make and everything built fine.
So I did some grepping in my sysroot and came across a number of places x86_64-oesdk-linux-gcc Important, I'm an oe-core user, not a poky users. So as Paul notes the exact string will be different. appeared. We'll focus on this file: /home/balister/sdks/oe-master/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/_sysconfigdata.py In this file file we have: 'BUILDPYTHON': 'python', 'CC': 'x86_64-oesdk-linux-gcc ', 'CCSHARED': '-fPIC', So this suggest the python install in the sdk knows what python it was built with. Unrelated side note, there is some fixup to map paths into the sdk in many variable, but not this one: -pipe' 'LDFLAGS=-Wl,-O1' 'CPPFLAGS=' 'CPP=x86_64-oesdk-linux-gcc -E ' 'PKG_CONFIG_PATH=/home/balister/src/oe-core/build/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-python/2.7.12-r1/recipe-sysroot/home/balister/sdks/oe-master/sysroots/x86_64-oesdk-linux/usr/lib/pkgconfig:/home/balister/src/oe-core/build/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-python/2.7.12-r1/recipe-sysroot/home/balister/sdks/oe-master/sysroots/x86_64-oesdk-linux/usr/share/pkgconfig' 'PKG_CONFIG_LIBDIR=/home/balister/src/oe-core/build/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-python/2.7.12-r1/recipe-sysroot/home/balister/sdks/oe-master/sysroots/x86_64-oesdk-linux/usr/lib/pkgconfig'",
in my case (poky) I see: 'BUILDPYTHON': 'python', 'CC': 'x86_64-pokysdk-linux-gcc ', 'CCSHARED': '-fPIC', It would seem that our environments are quite different, mine being "poky" based. I am afraid that unless I can reproduce the error, I will not be able to fix the problem. So please enumerate the steps you used to set up your "oe-core" environment, including the steps to buld the SDK.
??? Poky is oe-core + meta-poky + meta-yocto-bsp. How is this very different? Have you looked at the contents of the sysconfig file?
I really do not want to guess/assume anything regarding your setup.
Humour me and type: $ which x86_64-pokysdk-linux-gcc
(In reply to comment #22) > Humour me and type: > > $ which x86_64-pokysdk-linux-gcc After sourcing the SDK environment: $ source ~/sdk-11062-arm/environment-setup-armv5e-poky-linux-gnueabi juro@juro-Precision-T5610:~/bug-11062$ which x86_64-pokysdk-linux-gcc juro@juro-Precision-T5610:~/bug-11062$ These may be helpful: juro@juro-Precision-T5610:~/bug-11062$ which $CC /home/juro/sdk-11062-arm/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc juro@juro-Precision-T5610:~/bug-11062$ $PATH bash: /home/juro/sdk-11062-arm/sysroots/x86_64-pokysdk-linux/usr/bin:/home/juro/sdk-11062-arm/sysroots/x86_64-pokysdk-linux/usr/sbin:/home/juro/sdk-11062-arm/sysroots/x86_64-pokysdk-linux/bin:/home/juro/sdk-11062-arm/sysroots/x86_64-pokysdk-linux/sbin:/home/juro/sdk-11062-arm/sysroots/x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/home/juro/sdk-11062-arm/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi:/home/juro/sdk-11062-arm/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-uclibc:/home/juro/sdk-11062-arm/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-musl:/sbin:/usr/sbin/:/usr/local/bin:/usr/bin:/bin:/snap/bin: No such file or directory juro@juro-Precision-T5610:~/bug-11062$
which $CC gives you the cross compiler, not the "native" compiler that was used to build the python that runs in the sdk.
Juro, It appears he has answered your question. Please restate the question if you need more information.
Can you put an sdk built for the poky distro somewhere I can download it and take a look. I keep meaning to build one and compare, but am not getting there.
OK, Made some progress ... I downloaded the sdk from the autobuilder M3 build: poky-glibc-x86_64-core-image-sato-cortexa8hf-neon-toolchain-2.2+snapshot.sh The I source the env file and build -boot for the zc702 board and the build succeeds. The I type [balister@thuvia u-boot (master *)]$ which python /usr/bin/python So I see I am using python from the host, not from the sdk. So the sdk I build does include python in the sdk. The sdks I build have this file included in the image recipe: TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}" SDK_EXTRA_TOOLS = " nativesdk-python-cheetah \ nativesdk-python-netserver nativesdk-python-pprint \ nativesdk-python-pickle nativesdk-python-shell \ nativesdk-python-subprocess nativesdk-python-modules \ nativesdk-orc nativesdk-swig nativesdk-python-distutils \ nativesdk-python-xml nativesdk-python-compile \ nativesdk-cmake nativesdk-python-mako \ " SDK_EXTRA_TOOLS_task-populate-sdk-ext = "" So, if python is in the sdk, you can't build u-boot for the reasons I outline above.
(In reply to comment #27) > OK, Made some progress ... > > I downloaded the sdk from the autobuilder M3 build: > > poky-glibc-x86_64-core-image-sato-cortexa8hf-neon-toolchain-2.2+snapshot.sh > > The I source the env file and build -boot for the zc702 board and the build > succeeds. > > The I type > > [balister@thuvia u-boot (master *)]$ which python > /usr/bin/python > > So I see I am using python from the host, not from the sdk. > > So the sdk I build does include python in the sdk. > > The sdks I build have this file included in the image recipe: > > TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}" > > SDK_EXTRA_TOOLS = " nativesdk-python-cheetah \ > nativesdk-python-netserver nativesdk-python-pprint \ > nativesdk-python-pickle nativesdk-python-shell \ > nativesdk-python-subprocess nativesdk-python-modules \ > nativesdk-orc nativesdk-swig nativesdk-python-distutils \ > nativesdk-python-xml nativesdk-python-compile \ > nativesdk-cmake nativesdk-python-mako \ > " > > SDK_EXTRA_TOOLS_task-populate-sdk-ext = "" > > So, if python is in the sdk, you can't build u-boot for the reasons I > outline above. Hmmm, when I build the SDK the usual way (w/o SDK_EXTRA_TOOLS as above). i.e. $ bitbake -c populate_sdk core-image-minimal I get an SDK with python: $ which python /home/juro/sdk-11062-arm/sysroots/x86_64-pokysdk-linux/usr/bin/python which python3 /home/juro/sdk-11062-arm/sysroots/x86_64-pokysdk-linux/usr/bin/python3 and I have no problems building the image using this python. Using the same SDK as you have (pulled from http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3_M3.rc2/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-cortexa8hf-neon-toolchain-2.2+snapshot.sh ) I found out that python3 is there: $ which python3 /home/juro/sdk-m3-11062/sysroots/x86_64-pokysdk-linux/usr/bin/python3 But python is pulled from the host: $ which python /usr/bin/python This is ***probably*** by design, as the SDK does not contain python2, only python3. The SDK I built myself (Feb 27 or so) does contain both python versions. (I guess I should rebuild it again, to see if it is still the same)
Created attachment 3758 [details] Console output using SDK with python2 and python3
So python was replaced by pyhton3 in the SDK. I built a new SDK (using pyro) also containing python2, by adding this to local.conf: MACHINE="qemuarm" TOOLCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}" SDK_EXTRA_TOOLS = " \ nativesdk-python-core \ nativesdk-python-modules \ nativesdk-python-misc \ nativesdk-python-git \ " SDK_EXTRA_TOOLS_task-populate-sdk-ext = "" $ bitbake core-image-minimal -cpopulate_sdk After installing/sourcing the SDK to ~/sdk-11062-arm-may-4 I verified all pythons are in the SDK: $ which python /home/juro/sdk-11062-arm-may-4/sysroots/x86_64-pokysdk-linux/usr/bin/python $ which python2 /home/juro/sdk-11062-arm-may-4/sysroots/x86_64-pokysdk-linux/usr/bin/python2 $ which python3 /home/juro/sdk-11062-arm-may-4/sysroots/x86_64-pokysdk-linux/usr/bin/python3 Then I proceeded to build u-boot: $ git clone git://git.denx.de/u-boot.git $ cd u-boot $ make zynq_zc702_defconfig $ make I managed to get a clean build. I attached the console output. So it is possible to build u-boot using python2 from the SDK.
Philip, I am closing this bug as I have not been able to reproduce your problem. Please re-open the bug if needed. If you chose to do so, please provide detailed step-bu-step instructions to reproduce the problem.