On Tue, Jul 1, 2026, Yogesh Tyagi wrote: > Set CLANG_PATH to the native clang in the bindgen wrapper so clang-sys > uses the runnable host binary first, short-circuiting the llvm-config > lookup. The native wrapper already exports LIBCLANG_PATH the same way.
The reasoning is sound, and beyond the mesa rusticl case this also helps the rust-in-kernel build: kernel-yocto-rust.bbclass pulls in both clang-native and bindgen-cli-native, so native bindgen can hit the same target-clang-via-llvm-config lookup. Pinning CLANG_PATH to the native clang that matches the native libclang is the consistent thing to do there too, so: Reviewed-by: Bruce Ashfield <[email protected]> One thing while you're here: the recipe is BBCLASSEXTEND = "native nativesdk", but the wrapper fix is do_install:append:class-native() only. Unless I'm misreading it, that leaves the nativesdk bindgen wrapper with just LIBCLANG_PATH and no CLANG_PATH, so an SDK that runs bindgen (e.g. rust kernel-module development in the SDK, which is being wired up separately) would still hit the identical "could not run executable .../clang-NN" failure. If that's right, could you extend the CLANG_PATH export to the nativesdk wrapper as well? A shared helper (or a class-native/class-nativesdk pair pointing at the respective STAGING_BINDIR) would cover both. If nativesdk is already handled some other way, ignore me. Bruce
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#240483): https://lists.openembedded.org/g/openembedded-core/message/240483 Mute This Topic: https://lists.openembedded.org/mt/120052346/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
