[meson.bbclass] bindgen_clang_arguments lacks C++ include paths, breaks C++ bindgen (mesa rusticl)

[meson.bbclass] bindgen_clang_arguments lacks C++ include paths, breaks C++ bindgen (mesa rusticl)

[Royyan Zahir]

meson.bbclass builds the bindgen arguments as:

    def bindgen_args(d):
        args = '${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} --target=${TARGET_SYS}'

TOOLCHAIN_OPTIONS carries --sysroot, which is enough for C headers. It is not
enough for C++: when clang cross-compiles against a GCC sysroot it does not
infer the libstdc++ include directories from --sysroot alone, so any recipe
running bindgen over a C++ header fails to find the standard library.

mesa hits this with PACKAGECONFIG opencl, which turns on gallium-rusticl and
runs bindgen over rusticl_llvm_bindings.hpp with -x c++ -std=c++17:

    FAILED: src/gallium/frontends/rusticl/rusticl_llvm_bindings.rs
    .../recipe-sysroot/usr/include/llvm/ADT/DenseMapInfo.h:17:10:
        fatal error: 'cassert' file not found
    Unable to generate bindings: clang diagnosed error

Seen on mesa 26.0.5 with oe-core wrynose, aarch64 target, LLVM 22.1.3.

The missing arguments are the staged C++ headers:

    -I${STAGING_INCDIR}/c++/<version>
    -I${STAGING_INCDIR}/c++/<version>/${TARGET_SYS}

Our downstream workaround appends them to bindgen_clang_arguments in
meson.cross from a mesa bbappend, which works but is recipe-specific and
hardcodes a realpath glob over the staged header directory. It also has to run
after do_prepare_recipe_sysroot, since the glob is empty on a clean build.

Reporting rather than sending a patch because the right fix is a design call:
bindgen_args() is generic, so this affects any meson recipe doing C++ bindgen,
not just mesa. Options seem to be teaching bindgen_args() about the C++ include
paths unconditionally, gating it on whether the recipe does C++ bindgen, or
having clang-native resolve the GCC sysroot properly. A maintainer is better
placed to pick.

Happy to test a proposed fix on aarch64.

Re: [meson.bbclass] bindgen_clang_arguments lacks C++ include paths, breaks C++ bindgen (mesa rusticl)

[Paul Barker]

On Sat, 2026-09-19 at 21:28 +0400, Royyan Zahir wrote:
> meson.bbclass builds the bindgen arguments as:
> 
>     def bindgen_args(d):
>         args = '${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} --target=${TARGET_SYS}'
> 
> TOOLCHAIN_OPTIONS carries --sysroot, which is enough for C headers. It is not
> enough for C++: when clang cross-compiles against a GCC sysroot it does not
> infer the libstdc++ include directories from --sysroot alone, so any recipe
> running bindgen over a C++ header fails to find the standard library.
> 
> mesa hits this with PACKAGECONFIG opencl, which turns on gallium-rusticl and
> runs bindgen over rusticl_llvm_bindings.hpp with -x c++ -std=c++17:
> 
>     FAILED: src/gallium/frontends/rusticl/rusticl_llvm_bindings.rs
>     .../recipe-sysroot/usr/include/llvm/ADT/DenseMapInfo.h:17:10:
>         fatal error: 'cassert' file not found
>     Unable to generate bindings: clang diagnosed error
> 
> Seen on mesa 26.0.5 with oe-core wrynose, aarch64 target, LLVM 22.1.3.
> 
> The missing arguments are the staged C++ headers:
> 
>     -I${STAGING_INCDIR}/c++/<version>
>     -I${STAGING_INCDIR}/c++/<version>/${TARGET_SYS}
> 
> Our downstream workaround appends them to bindgen_clang_arguments in
> meson.cross from a mesa bbappend, which works but is recipe-specific and
> hardcodes a realpath glob over the staged header directory. It also has to run
> after do_prepare_recipe_sysroot, since the glob is empty on a clean build.
> 
> Reporting rather than sending a patch because the right fix is a design call:
> bindgen_args() is generic, so this affects any meson recipe doing C++ bindgen,
> not just mesa. Options seem to be teaching bindgen_args() about the C++ include
> paths unconditionally, gating it on whether the recipe does C++ bindgen, or
> having clang-native resolve the GCC sysroot properly. A maintainer is better
> placed to pick.
> 
> Happy to test a proposed fix on aarch64.

Hi,

Please could you share enough information to reproduce this build
failure. The bitbake command you ran and the initial output showing
layer versions, DISTRO, etc may be sufficient.

Best regards,

-- 
Paul Barker

Re: [meson.bbclass] bindgen_clang_arguments lacks C++ include paths, breaks C++ bindgen (mesa rusticl)

[Royyan Zahir]

Hi Paul,

Thanks for looking. Versions first, then the trigger, then what I have not yet
established.

Layers, all pinned:

  openembedded-core  wrynose  f7397af248e1e338929d70a910b0fbc2341528ec
  bitbake            2.18     0ad6c1c34a5e07a5f8dd66ab248c1e7b37b69fa9
  meta-openembedded  wrynose  14282a02be9c74a1276a7cda7d6c89e054699a11
  meta-qcom          wrynose  ef0004df267743cc89d6a09bc724bc99ff541c01

Target is aarch64, mesa 26.0.5, LLVM 22.1.3, bindgen from bindgen-cli-native.

The trigger is only this:

  DISTRO_FEATURES:append = " opencl"

which selects mesa's PACKAGECONFIG[opencl], so -Dgallium-rusticl=true, and the
rusticl frontend runs bindgen over a C++ header. The failing command ends with
-x c++ -std=c++17 on rusticl_llvm_bindings.hpp, and clang cannot find cassert
from llvm/ADT/DenseMapInfo.h.

What I cannot give you is a runnable command line: our DISTRO and MACHINE are
in a layer I cannot share, and I have not yet reduced this to stock poky. I
tried to on the shared builder this morning and it refused before parsing with

  ERROR: User namespaces are not usable by BitBake, possibly due to AppArmor.

so that attempt proved nothing. Our own builds go through a wrapper that
handles it.

My reading is that nothing platform-specific is involved: bindgen_args() in
meson.bbclass passes HOST_CC_ARCH, TOOLCHAIN_OPTIONS and --target, and none of
those carry the libstdc++ include directories that clang needs when it
cross-compiles against a GCC sysroot. Any meson recipe running bindgen over a
C++ header should hit it. If that reasoning is wrong I would rather know than
have you chase our stack.

Happy to build a stock qemuarm64 case with opencl in DISTRO_FEATURES on a
machine without the namespace restriction and report back, or to test a patch
on aarch64, whichever is more useful.

Royyan

Re: [meson.bbclass] bindgen_clang_arguments lacks C++ include paths, breaks C++ bindgen (mesa rusticl)

[Paul Barker]

On Mon, 2026-09-21 at 13:11 +0400, Royyan Zahir wrote:
> Hi Paul,
> 
> Thanks for looking. Versions first, then the trigger, then what I have not yet
> established.
> 
> Layers, all pinned:
> 
>   openembedded-core  wrynose  f7397af248e1e338929d70a910b0fbc2341528ec
>   bitbake            2.18     0ad6c1c34a5e07a5f8dd66ab248c1e7b37b69fa9
>   meta-openembedded  wrynose  14282a02be9c74a1276a7cda7d6c89e054699a11
>   meta-qcom          wrynose  ef0004df267743cc89d6a09bc724bc99ff541c01
> 
> Target is aarch64, mesa 26.0.5, LLVM 22.1.3, bindgen from bindgen-cli-native.
> 
> The trigger is only this:
> 
>   DISTRO_FEATURES:append = " opencl"
> 
> which selects mesa's PACKAGECONFIG[opencl], so -Dgallium-rusticl=true, and the
> rusticl frontend runs bindgen over a C++ header. The failing command ends with
> -x c++ -std=c++17 on rusticl_llvm_bindings.hpp, and clang cannot find cassert
> from llvm/ADT/DenseMapInfo.h.
> 
> What I cannot give you is a runnable command line: our DISTRO and MACHINE are
> in a layer I cannot share, and I have not yet reduced this to stock poky. I
> tried to on the shared builder this morning and it refused before parsing with
> 
>   ERROR: User namespaces are not usable by BitBake, possibly due to AppArmor.
> 
> so that attempt proved nothing. Our own builds go through a wrapper that
> handles it.
> 
> My reading is that nothing platform-specific is involved: bindgen_args() in
> meson.bbclass passes HOST_CC_ARCH, TOOLCHAIN_OPTIONS and --target, and none of
> those carry the libstdc++ include directories that clang needs when it
> cross-compiles against a GCC sysroot. Any meson recipe running bindgen over a
> C++ header should hit it. If that reasoning is wrong I would rather know than
> have you chase our stack.
> 
> Happy to build a stock qemuarm64 case with opencl in DISTRO_FEATURES on a
> machine without the namespace restriction and report back, or to test a patch
> on aarch64, whichever is more useful.

Yes, I'd like you to confirm that the error happens on stock
poky/qemuarm64 with just the DISTRO_FEATURES change to enable opencl.

Also, please quote the email you're replying to so it's easier to follow
the conversation.

Best regards,

-- 
Paul Barker

Re: [meson.bbclass] bindgen_clang_arguments lacks C++ include paths, breaks C++ bindgen (mesa rusticl)

[Royyan Zahir]

On Mon, 21 Sep 2026, Paul Barker wrote:
> Yes, I'd like you to confirm that the error happens on stock
> poky/qemuarm64 with just the DISTRO_FEATURES change to enable opencl.
>
> Also, please quote the email you're replying to so it's easier to follow
> the conversation.

Sorry about the quoting, fixed here.

Ran it, and it does NOT reproduce on stock poky. So my report was wrong, sorry for the noise.

oe-core f7397af248 + bitbake 2.18 0ad6c1c34, nothing else, local.conf was just:

  MACHINE = "qemuarm64"
  DISTRO_FEATURES:append = " opencl"

bitbake mesa: 2659 tasks, all succeeded.

rusticl was definitely on and bindgen definitely ran, so it is not that the path was skipped:

  gallium-rusticl=true                                    (log.do_configure)
  bindgen appears 4x in log.do_compile
  build/src/gallium/frontends/rusticl/rusticl_llvm_bindings.rs   13502 bytes, generated fine

And the interesting bit: bindgen_clang_arguments in that build has no C++ include paths either, same as ours:

  bindgen_clang_arguments = ['-mcpu=cortex-a57+crc', '-mbranch-protection=standard',
    '-fstack-protector-strong', '-O2', '-D_FORTIFY_SOURCE=2', '-Wformat',
    '-Wformat-security', '-Werror=format-security',
    '--sysroot=.../mesa/26.0.5/recipe-sysroot', '--target=aarch64-oe-linux']

so clang finds cassert anyway. My "any recipe doing C++ bindgen will hit this" claim is just wrong, ignore it.

One difference I can see: stock poky pulls LLVM 22.1.8, our stack is on 22.1.3 (meta-qcom pins it). The failure is clang chasing cassert from llvm/ADT/DenseMapInfo.h, so an older LLVM header pulling in something slightly different is my current guess. Guess only, I have not tested it yet.

Next thing I can do is the same stock build plus meta-qcom and its LLVM pin, one variable at a time, and see which one flips it. Will report back if you think it is worth it, otherwise happy to just carry our bbappend and drop this.

Royyan