Hi, when I recently tried to fix a lot of recipes in my meta-python-ai layer at https://github.com/zboszor/meta-python-ai to actually be able to cross-compile, I came across an interesting issue related to python modules using cmake internally in their build frameworks.
Here's the python3-onnx commit that needed tweaks in toolchain.cmake: https://github.com/zboszor/meta-python-ai/commit/a1b466ec0db66866ff1c817fd707c33837ec0225 The problem was that the pre-release onnx 1.20.0rc1 uses nanobind, which in turn seems to utilize both STAGING_DIR and STAGING_DIR_NATIVE as currently specified in CMAKE_FIND_ROOT_PATH. Then cmake rightfully complains about libraries in recipe-sysroot shadowed by the ones in recipe-sysroot-native. Removing STAGING_DIR_NATIVE from CMAKE_FIND_ROOT_PATH then made it necessary to specify * the full path to ninja in CMAKE_MAKE_PROGRAM * the full path to compilers in OECMAKE_C_COMPILER and OECMAKE_CXX_COMPILER * some other things, like the full path to protoc and python3, because for some reason, they were not picked up from PATH(???) My questions are regarding cmake.bbclass: Would it make sense to make the use of STAGING_DIR_NATIVE in CMAKE_FIND_ROOT_PATH for target builds optional? At least provide a choice to opt-out? Would it make sense to specify the full path to C/C++ compilers by default? Would it make sense to add CMAKE_MAKE_PROGRAM and the full path to the proper binary (make or ninja) to toolchain.cmake, depending on the value of OECMAKE_GENERATOR? Best regards, Zoltán Böszörményi
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#226609): https://lists.openembedded.org/g/openembedded-core/message/226609 Mute This Topic: https://lists.openembedded.org/mt/116388438/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
