mesa 25 upgrade is newly building clc pieces for which it use mesa_clc tool to do the conversion to SPIRV backend and utilizes clang to do the work underneath. Clang argument are passed on commandline after -- separator. This works ok when rm_work is not enabled however when INHERIT:append = " rm_work" in local.conf and use MACHINE = "qemux86-64" Then build mesa bitbake -ccleansstate mesa-native mesa bitbake mesa It ends up in errors e.g. /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux/mesa/25.0.2/recipe-sysroot-native/usr/bin/mesa_clc ../mesa-25.0.2/src/intel/shaders/libintel_shaders.h ../mesa-25.0.2/src/intel/shaders/generate.cl ../mesa-25.0.2/src/intel/shaders/generate_draws.cl ../mesa-25.0.2/src/intel/shaders/generate_draws_iris.cl ../mesa-25.0.2/src/intel/shaders/query_copy.cl ../mesa-25.0.2/src/intel/shaders/util.cl -o src/intel/shaders/intel_gfx90_shaders.spv -- -DNDEBUG=1 -DGFX_VERx10=90 -I/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux/mesa/25.0.2/mesa-25.0.2/src/intel/shaders/. -I/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux/mesa/25.0.2/mesa-25.0.2/src/compiler/libcl -I/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux/mesa/25.0.2/mesa-25.0.2/src -I/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux/mesa/25.0.2/mesa-25.0.2/src/intel -I/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux/mesa/25.0.2/build/src/intel -I/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux/mesa/25.0.2/mesa-25.0.2/src/intel/genxml <built-in>:1:10: fatal error: 'opencl-c-base.h' file not found Error executing LLVM compilation action.
I manually appended --isysroot=/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux/mesa/25.0│ │.2/recipe-sysroot this gets into next error Couldn't create Clang invocation.
Between this and the meta-clang breakage our llvm/clang recipes are pretty broken. I'm close to advocating we revert the llvm changes in core... Khem, Dmitry: can you work out how to resolve this?
With the following I can successfully build nodistro + mesa doing the build package-by-package, so that rm_work can kick in inbetween. - current github/master - https://lore.kernel.org/openembedded-core/20250418-mesa-25-fixes-v2-0-e110ccfe291f@oss.qualcomm.com/ - https://github.com/kraj/meta-clang/pull/1085 I definitely don't think that reverting llvm / mesa in acceptable solution: this means shipping a very outdated and not supported component.
(In reply to Ross Burton from comment #2) > Between this and the meta-clang breakage our llvm/clang recipes are pretty > broken. > > I'm close to advocating we revert the llvm changes in core... Khem, Dmitry: > can you work out how to resolve this? I have pushed a new branch to contrib tree which contains a clang merge into core. https://web.git.yoctoproject.org/poky-contrib/log/?h=kraj/clang-merge-2 Please look into it and lets make it work. I can build mesa with this and also full featured clang compiler. I will start adapting meta-clang to remove clang and make adjustments as needed to work with clang coming from core. I think this will straighten the path forward.
(In reply to Dmitry Baryshkov from comment #3) > With the following I can successfully build nodistro + mesa doing the build > package-by-package, so that rm_work can kick in inbetween. > > - current github/master > - > https://lore.kernel.org/openembedded-core/20250418-mesa-25-fixes-v2-0- > e110ccfe291f@oss.qualcomm.com/ I have staged these patches into kraj/clang-merge-2 branch > - https://github.com/kraj/meta-clang/pull/1085 > I think this wont be needed. > I definitely don't think that reverting llvm / mesa in acceptable solution: > this means shipping a very outdated and not supported component. yes, I am hopeful that we don't have to take this step.
From IRC, #yocto Randy: khem: RP thinks that this issue has been resolved, do you agree? Khem: I think yes,I have not seen this failures on CI systems for some weeks now