From: Royyan Zahir <royzah@gmail.com>
To: openembedded-core@lists.openembedded.org
Cc: Paul Barker <paul@pbarker.dev>
Subject: Re: [meson.bbclass] bindgen_clang_arguments lacks C++ include paths, breaks C++ bindgen (mesa rusticl)
Date: Mon, 21 Sep 2026 19:52:28 +0400 [thread overview]
Message-ID: <20260921155228.256241-1-royzah@gmail.com> (raw)
In-Reply-To: <20260921091118.3545921-1-royzah@gmail.com>
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
prev parent reply other threads:[~2026-09-21 16:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-19 17:28 [meson.bbclass] bindgen_clang_arguments lacks C++ include paths, breaks C++ bindgen (mesa rusticl) Royyan Zahir
2026-09-21 8:14 ` Paul Barker
2026-09-21 9:11 ` Royyan Zahir
2026-09-21 10:09 ` Paul Barker
2026-09-21 15:52 ` Royyan Zahir [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260921155228.256241-1-royzah@gmail.com \
--to=royzah@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul@pbarker.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox