kraj/meta-clang

building clang conflicts with llvm

lumag opened this issue · 4 comments

lumag commented

Describe the bug
I have meta-clang layer enabled, but the default toolchain is still pointed to the standard gcc from OE-Core.
I tried building both llvm and clang pacakges at the same time. However this fails with the following error:

ERROR: llvm-17.0.6-r0 do_packagedata_setscene: Recipe llvm is trying to install files into a shared area when those files already exist. The files and the manifests listing them are:
  /home/lumag/Projects/RPB/build-rpb/tmp-rpb-glibc/pkgdata/qcom-armv8a/runtime-reverse/liblto17
    (matched in manifest-qcom_armv8a-clang.packagedata)
Please adjust the recipes so only one recipe provides a given file. 
WARNING: Logfile for failed setscene task is /home/lumag/Projects/RPB/build-rpb/tmp-rpb-glibc/work/armv8a-linaro-linux/llvm/17.0.6/temp/log.do_packagedata_setscene.3213860
WARNING: Setscene task (/home/lumag/Projects/RPB/build-rpb/conf/../../layers/openembedded-core/meta/recipes-devtools/llvm/llvm_git.bb:do_packagedata_setscene) failed with exit code '1' - real task will be run instead
ERROR: llvm-17.0.6-r0 do_packagedata: Recipe llvm is trying to install files into a shared area when those files already exist. The files and the manifests listing them are:
  /home/lumag/Projects/RPB/build-rpb/tmp-rpb-glibc/pkgdata/qcom-armv8a/runtime-reverse/liblto17
    (matched in manifest-qcom_armv8a-clang.packagedata)
Please adjust the recipes so only one recipe provides a given file. 

To Reproduce
Steps to reproduce the behavior:

  1. Setup a build with OE-Core and meta-lang layers, don't change any defaults
  2. execute bitbake llvm llvm-native clang clang-native

Expected behavior
It is possible to build both recipes at the same time

Additional context
I stumbled upon the LLVM and Clang recipes conflict when I was trying to build the OpenCL support in mesa. In addition to the mentioned conflict, it also provides the following conflict (because it pulls in both llvm (natively) and clang (via libclc dependency)).

Exception: FileExistsError: [Errno 17] File exists: '/home/lumag/Projects/RPB/build-rpb/tmp-rpb-glibc/sysroots-components/armv8a/llvm/usr/lib/libLLVMExegesisAArch64.a' -> '/home/lumag/Projects/RPB/build-rpb/tmp-rpb-glibc/work/armv8a-linaro-linux/mesa/23.3.1/recipe-sysroot/usr/lib/libLLVMExegesisAArch64.a'

Enabling the PREFERRED_PROVIDER / PROVIDES from README.md seems to fix this issue. Generally I think that these settings should be made a default in meta-clang.

kraj commented

try building llvm recipe with LLVM_TOOL_LTO_BUILD=OFF

lumag commented

@kraj I will check this later, but please also see the additional context part.

So the fixup should be enabling PREFERRED_PROVIDER / PROVIDES if bblayeres.conf include meta-clang?

try building llvm recipe with LLVM_TOOL_LTO_BUILD=OFF

It causes more file conflicts with LLVM_TOOL_LTO_BUILD=OFF:

Error: Transaction test error:                                                                                                                                                                                                                
  file /usr/lib/libLLVM-17.so conflicts between attempted installs of llvm-libllvm-17.0.6-r0.core2_64 and clang-libllvm-17.0.6-r0.core2_64
  file /usr/bin/bugpoint conflicts between attempted installs of llvm-17.0.6-r0.core2_64 and clang-17.0.6-r0.core2_64                                                                                                                         
  file /usr/bin/dsymutil conflicts between attempted installs of llvm-17.0.6-r0.core2_64 and clang-17.0.6-r0.core2_64  
  ...snip...
  file /usr/bin/opt conflicts between attempted installs of llvm-17.0.6-r0.core2_64 and clang-17.0.6-r0.core2_64
  file /usr/bin/sanstats conflicts between attempted installs of llvm-17.0.6-r0.core2_64 and clang-17.0.6-r0.core2_64
  file /usr/bin/verify-uselistorder conflicts between attempted installs of llvm-17.0.6-r0.core2_64 and clang-17.0.6-r0.core2_64

I still think remove liblto17 from llvm is the clean and direct fix just I sent the patch to oe-core.