2026. 07. 08. 14:41 keltezéssel, Bruce Ashfield via lists.openembedded.org írta:
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]>
Tested-by: Zoltán Böszörményi <[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 (#240541):
https://lists.openembedded.org/g/openembedded-core/message/240541
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]]
-=-=-=-=-=-=-=-=-=-=-=-
