Branch 'dunfell-clang12' builds clang 10.0.1

[telkamp]

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:

• it builds clang 10 (not clang 12)
• it does not generate libclang_rt.builtins-armhf.a (maybe more libraries are missing, but this was the first one) Would it be better to use the "dunfell" branch (instead of "dunfell-clang12")?

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]

yeah try dunfell first.

[telkamp]

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]

@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]

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]

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

[kraj]

@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]

@kraj That did it. Thanks!

[telkamp]

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]

@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]

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...