Re: [OE-core] [PATCH] bindgen-cli: set CLANG_PATH in native wrapper to native clang

["Tyagi, Yogesh" <yogesh.tyagi@intel.com>]

On Wed, 2026-07-08 at 05:41 -0700, Bruce Ashfield wrote:
> 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 <bruce.ashfield@gmail.com>
> 
> 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.


Thanks Bruce, good catch — you're right that the SDK case was
uncovered.

One clarification: in v1 the recipe only had do_install:append:class-
native(), so the nativesdk bindgen had no wrapper at all — not even
LIBCLANG_PATH. Same failure mode, just with nothing set rather than
only CLANG_PATH missing.

v2 adds a class-nativesdk wrapper. I went with an explicit class-
native/class-nativesdk pair rather than a shared helper, because the
staging dirs aren't symmetric between the two classes and a shared
"point at the respective STAGING_BINDIR" helper actually breaks:

native uses STAGING_*_NATIVE, which sits entirely under base_prefix, so
create_wrapper's relocation rewrites it cleanly.
nativesdk's STAGING_LIBDIR/STAGING_BINDIR are STAGING_DIR_HOST (recipe-
sysroot, i.e. TMPDIR) + the SDK path. create_wrapper only relocates the
base_prefix substring, so the recipe-sysroot prefix stays baked into
the shipped wrapper. I hit exactly that: do_package_qa failed with
contains reference to TMPDIR [buildpaths].
So the nativesdk wrapper uses the plain on-target ${libdir}/${bindir}
instead, which relocate fully. Verified by building both variants:
bindgen-cli-native and nativesdk-bindgen-cli both build and pass
package QA, and both generated wrappers come out relocatable as
CLANG_PATH=$realdir/../../usr/bin/clang.

Since the patch grew a new task, I dropped your Reviewed-by from v2 —
happy to carry it if you're good with the nativesdk addition.

> 
> Bruce