Hi Kasper, hi Sean Yes, I did some trials with C/C++. There are 3 different approaches which I investigated into. All come with pros and cons.
1. compiling for the SDK (native) is easy and running the resulting binaries on the host also works. It is also relatively easy to create an tool-chain environment file that can be used to use the host toolchain with the native Yocto sysroots. I guess that's the proposed approach here. The downside to this idea is that it is not really reproducible. Compiling for the host uses the compiler and other tools provided by the host distribution. Since these may be different, the result and errors may also be different. Also, all recipes involved must be patched with the line BBCLASSEXTEND = "native nativesdk", which cannot be mainlined unless it makes sense to use a recipe as a native recipe in general. As far as I know, the Yocto project rejects such only partially implementable ideas for good reasons. 2. Stick to cross-compiling also for this use case, but compile for a MACHINE (e.g. Qemu) with the same CPU architecture as the host has can work as well. The build part is solved acc. the concepts of Yocto. But executing the binaries on the host is not that straight forward. For example this does not work even if xz is compiled for the same ARCH as the host has: ./build/tmp/work/corei7-64-ccp-linux/xz/5.2.6-r0/image/usr/bin/xz -- help bash: ./build/tmp/work/corei7-64-ccp-linux/xz/5.2.6- r0/image/usr/bin/xz: cannot execute: required file not found With a little trick (using the correct linker) it works: LD_LIBRARY_PATH="./build/tmp/work/corei7-64-ccp-linux/xz/5.2.6- r0/recipe-sysroot/lib:./build/tmp/work/corei7-64-ccp-linux/xz/5.2.6- r0/recipe-sysroot/usr/lib" ./build/tmp/work/corei7-64-ccp- linux/xz/5.2.6-r0/recipe-sysroot/lib/ld-linux-x86-64.so.2 ./build/tmp/work/corei7-64-ccp-linux/xz/5.2.6-r0/image/usr/bin/xz -- help Usage: ./projects/ccp-sd-virt/tmp/work/corei7-64-ccp-linux/xz/5.2.6- r0/image/usr/bin/xz [OPTION]... [FILE]... Compress or decompress FILEs in the .xz format. ... 3. Use Qemu to execute the binaries. This approach is transparently implemented with my SDK here: https://git.yoctoproject.org/poky-contrib/log/?h=adrianf/devtool-ide If for example the unit tests are executed in VSCode they just run even if they have a different architecture than the host has. This is fully supported by meson and by cmake. The disadvantage of this approach is that Qemu is not transparent when it comes to debugging and probably other use cases. Regards, Adrian
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#188722): https://lists.openembedded.org/g/openembedded-core/message/188722 Mute This Topic: https://lists.openembedded.org/mt/101633983/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
