| Summary: | nativesdk programs are not executed in eSDK | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] eSDK | Reporter: | Lukasz Majewski <l.majewski> |
| Component: | eSDK | Assignee: | Paul Eggleton <bluelightning> |
| Status: | RESOLVED INVALID | QA Contact: | Francisco Pedraza <francisco.j.pedraza.gonzalez> |
| Severity: | critical | ||
| Priority: | Undecided | ||
| Version: | 2.4.2 | ||
| Target Milestone: | --- | ||
| Hardware: | x86 | ||
| OS: | arm | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
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. |
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