The problem is with bundling some program to eSDK. For example iperf3. Prerequisite: iperf3_%.bbappend with BBCLASSEXTEND = "native nativesdk" When I do add it to TOOLCHAIN_HOST_TASK's nativesdk-packagegroup-sdk-host as RDEPENDS_${PN} += " nativesdk-iperf3" After eSDK deployment on developer's machine, sourcing environment: . /opt/scs_sdk/environment-setup-armv7ahf-neon-poky-linux-gnueabi When I try to execute iperf3: iperf3 -bash: /opt/scs_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/iperf3: No such file or directory file iperf3 /opt/scs_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/file: line 4: /opt/scs_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/file.real: No such file or directory The same error can be observed with other binaries (like htop, nano, etc) The iperf3 is working after deploying SDK. It is also usable from: x86_64-buildtools-nativesdk-standalone-2.4.2.sh I've double check and: SDK_INCLUDE_TOOLCHAIN = “1” - so we shall install in eSDK the same set of binaries as we did with SDK. Why I cannot use iperf3 (and others) from eSDK? Is there any way to combine x86_64-buildtools-nativesdk-standalone-2.4.2.sh and eSDK to have binaries from former and devtool from latter? Or maybe I'm fundamentally wrong and miss some obvious thing? Thanks in advance for help, Łukasz
Please find detailed explanation of the problem (if somebody will encounter similar issue in the future): The problem is with hardcoded paths in eSDK. To run program from eSDK, some binaries/programs are needed from earlier installed SDK - like /opt/<distro>/2.4.2/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 Otherwise presented below errors pop up. This means that eSDK depends on SDK.
As discussed on the #yocto IRC channel - this is only a workaround. The eSDK and SDK shall work with relocating to other paths than default one.
Detailed SHA1s: meta meta-poky meta-yocto-bsp = "heads/yocto 2.4.2:342fbd6a3e57021c8e28b124b3adb241936f3d9d" meta-oe meta-networking meta-python = "rocko:dacfa2b1920e285531bec55cd2f08743390aaf57"
It may not be clear from the documentation, but the eSDK isn't currently designed to ship nativesdk binaries - the assumption is that native binaries will be used instead. There are a couple of means of adding components that aren't already added through the dependency chain for the image, but they aren't particularly nice - see bug 10600 (this is something we would like to fix in future). So for the eSDK specifically you would instead be adding iperf3-native (and *not* changing TOOLCHAIN_HOST_TASK). Hope this helps.
Hi Paul, Thank you for the reply. (In reply to comment #4) > It may not be clear from the documentation, but the eSDK isn't currently > designed to ship nativesdk binaries - the assumption is that native binaries > will be used instead. I see. Indeed it is a bit misleading. > There are a couple of means of adding components that > aren't already added through the dependency chain for the image, but they > aren't particularly nice - see bug 10600 (this is something we would like to > fix in future). So for the eSDK specifically you would instead be adding > iperf3-native (and *not* changing TOOLCHAIN_HOST_TASK). Hope this helps. Yes, correct. The approach with adding meta-extsdk-toolchain works properly for eSDK. However, one needs to be careful if proper *-native package is found. Thanks for help.