Re: [PATCH v2 0/7] clang-merge: Bring clang recipes from meta-clang

[Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>]

On 26/04/2025 00:18, Khem Raj wrote:
> On 4/25/25 4:18 AM, Dmitry Baryshkov wrote:
>> On Fri, Apr 25, 2025 at 02:04:53PM +0300, Dmitry Baryshkov wrote:
>>> On Fri, Apr 25, 2025 at 01:27:45PM +0300, Dmitry Baryshkov wrote:
>>>> On Thu, Apr 24, 2025 at 10:43:21PM -0700, Khem Raj wrote:
>>>>> Latest mesa 25+ needs libclang during build for tools like mesa_clc,
>>>>> we enahnced already existing llvm recipe to build pieces of clang as
>>>>> well, which worked for mesa's needs but broke static clang compiler
>>>>> provided by meta-clang due to newfound conflicts, since clang is now
>>>>> built with llvm recipe from core and also by meta-clang and they
>>>>> compete for same namespace, an attempt to make them co-habit did 
>>>>> reveal
>>>>> more difficulties. Clang compiler from meta-clang is not able to use
>>>>> llvm libraries from core since they patch them differently.
>>>>>
>>>>> This patch series therefore brings clang and all recipes that build 
>>>>> from
>>>>> llvm sources into core. With this changeset, clang recipes can be 
>>>>> removed
>>>>> from meta-clang there is a pull request for that already [1]
>>>>> As an aside, we only build clang once and use it for meta-clang needs
>>>>> and core needs.
>>>>>
>>>>> With this, meta-clang can depend upon core layer to provide clang and
>>>>> related recipes, meta-clang will still provide the toolchain policies
>>>>> around clang based toolchains. Clang compiler from core, while usable
>>>>> for mesa is not yet fully usable out of box, since we need to workout
>>>>> the multi-toolchain architecture for core, which will be done in next
>>>>> phase after this merge.
>>>>>
>>>>> [1] https://github.com/kraj/meta-clang/pull/1088
>>>>>
>>>>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>>>>
>>>> With the following lines in local.conf I got the RPROVIDES error:
>>>>
>>>> PACKAGECONFIG:append:pn-mesa = " opencl libclc gallium-llvm "
>>>> PACKAGECONFIG:append:pn-mesa-native = " opencl libclc gallium-llvm "
>>>> PACKAGECONFIG:append:pn-nativesdk-mesa = " opencl libclc gallium-llvm "
>>>>
>>>> $ DISTRO=poky MACHINE=qemux86-64 bitbake mesa
>>>>
>>>> ERROR: Nothing RPROVIDES 'spirv-llvm-translator' (but /home/lumag/ 
>>>> Projects/RPB/build-rpb/conf/../../layers/openembedded-core/meta/ 
>>>> recipes-graphics/mesa/mesa.bb RDEPENDS on or otherwise requires it)
>>>> NOTE: Runtime target 'spirv-llvm-translator' is unbuildable, 
>>>> removing...
>>>> Missing or unbuildable dependency chain was: ['spirv-llvm-translator']
>>>> ERROR: Required build target 'mesa' has no buildable providers.
>>>> Missing or unbuildable dependency chain was: ['mesa', 'spirv-llvm- 
>>>> translator']
>>>
>>> After adding the RPROVIDES for libclc and spirv-llvm-translator, the
>>> same command fails with:
>>>
>>> ERROR: mesa-2_25.0.2-r0 do_package_qa: QA Issue: File /usr/lib/ 
>>> libMesaOpenCL.so.1.0.0 in package libopencl-mesa contains reference 
>>> to TMPDIR [buildpaths]
> 
> I can see this on qemux86-64 as well.
> 
>>> ERROR: mesa-2_25.0.2-r0 do_package_qa: Fatal QA errors were found, 
>>> failing task.
>>> ERROR: Logfile of failure stored in: /home/lumag/Projects/RPB/build- 
>>> rpb/tmp-poky/work/core2-64-poky-linux/mesa/25.0.2/temp/ 
>>> log.do_package_qa.3491435
>>> ERROR: Task (/home/lumag/Projects/RPB/build-rpb/conf/../../layers/ 
>>> openembedded-core/meta/recipes-graphics/mesa/mesa.bb:do_package_qa) 
>>> failed with exit code '1'
>>
>> As with the v1, building with the RPROVIDES and PACKAGECONFIG being set
>> for poky/qemuarm64 fails with:
>>
>> /home/lumag/Projects/RPB/build-rpb/tmp-poky/work/cortexa57-poky-linux/ 
>> mesa/25.0.2/recipe-sysroot/usr/include/llvm/ADT/DenseMapInfo.h:17:10: 
>> fatal error: 'cassert' file not f
>> ound
>> Unable to generate bindings: clang diagnosed error: /home/lumag/ 
>> Projects/RPB/build-rpb/tmp-poky/work/cortexa57-poky-linux/mesa/25.0.2/ 
>> recipe-sysroot/usr/include/llvm/ADT/Den
>> seMapInfo.h:17:10: fatal error: 'cassert' file not found
>>
> 
> this header comes from C++ runtime package either libstdc++ or libcxx, 
> do you still see this with v2 series ?

Yes, I've been running the test against v2 + RPROVIDES

-- 
With best wishes
Dmitry