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

[Khem Raj <raj.khem@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 3941 bytes --]

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 ?

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2613 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]