search

kraj / meta-clang

Clang C/C++ cross compiler and runtime for OpenEmbedded/Yocto Project
MIT License
162 stars 206 forks source link

Branch 'dunfell-clang12' builds clang 10.0.1 #558

Open telkamp opened 2 years ago

telkamp commented 2 years ago

I have to use Yocto Dunfell, because this is provided by the BSP. I've built the meta-clang branch "dunfell-clang12", but this has two problems:

Another option might be to select the master branch of meta-clang, but Dunfell is not supported officially (LAYERSERIES_COMPAT_clang-layer = "hardknott honister") Maybe meta-clang could be modified, e.g. it expects busybox 1.35 that is a bit to new for dunfell. Is there anyone who already tried this? I would like to know if this would be an easy or a really hard job to do...

kraj commented 2 years ago

yeah try dunfell first.

telkamp commented 2 years ago

The commits in the dunfell branch seems to be more recent than in dunfell-clang12 brunch, but unfortunately the LLVMVERSION is still 10.0.1: conf/layer.conf#L32

In receipes-devtools/clang/common.inc there are patches for the LLVM code, so I don't think it might be a good idea to increase the LLVMVERSION to 13.0.1 in the dunfell branch. Would it be more promising to try to get the master branch working with dunfell?

kraj commented 2 years ago

@telkamp you can set LLVMVERSION = "12.0.0" in conf/layer.conf when using dunfell_clang12 branch, I think this is missing in that branch.

When it comes to using clang13 with dunfell, I would be open for that as well. However using master branch as such might not work well with dunfell branch. So you have to backport the clang13 recipes like its done in dunfell_clang12 branch perhaps create a new branch dunfell_clang13

telkamp commented 2 years ago

Thank you for your assessment. The dunfell-clang12 branch is not very different from the dunfell branch. But I've seen that there is another (also stale) branch named clang12, pretending to be compatible to dunfell: LAYERSERIES_COMPAT_clang-layer = "dunfell hardknott honister" This branch seems really to use clang-12 :-)

Since on the dunfell branch there are only 3 commits newer than on the clang12 branch, it might make more sense to continue with the clang12 branch. What do you think?

jwinarske commented 2 years ago

@kraj I tried setting LLVMVERSION = "12.0.0" in conf/layer.conf, and cleaned the build. It still picks 10.

kraj commented 2 years ago

@jwinarske I think the branch was not uptodate it should be same as clang12, now the branch has been updated so both clang12 and dunfell-clang12 should be same. Please update your checkout and retry

jwinarske commented 2 years ago

@kraj That did it. Thanks!

telkamp commented 2 years ago

Thank you, this works also for me now. @jwinarske Do you get the compiler-rt for the target (libclang_rt.builtins-armhf.a)? This is missing here, and I'm not sure if this is due to a mismatch in the yocto base layers (stm32mp)

jwinarske commented 2 years ago

@telkamp Here's an example that builds compiler-rt for target: https://github.com/meta-flutter/meta-flutter/blob/dunfell/recipes-graphics/toyota/ivi-homescreen.inc

Are you following a similar pattern?

telkamp commented 2 years ago

Are you following a similar pattern?

No, I've built the toolchain installer poky-tiny-...-stm32mp1-toolchain-3.1.13.sh. The toolchain works, but the libclang_rt.builtins-armhf.a is missing. Maybe the lib is not built because the toolchain receipe has no dependency to it? I think I should include a receipe with a dependency as shown in your example, maybe this will also ensure that libclang_rt.builtins-armhf.a is available for the toolchain...