linux/meta-clang.git, branch scarthgap

clang : Fix CVE-2024-7883

2026-03-16T21:09:55+00:00

This patch applies the upstream fix as referenced in [2], using the commit shown in [1]. [1] https://github.com/llvm/llvm-project/commit/33411d520783189c31e9936a67371198d6da5f25 [2] https://security-tracker.debian.org/tracker/CVE-2024-7883 Signed-off-by: Anil Dongare

clang.bbclass: Allow overriding LTO:toolchain-clang

2026-02-11T04:55:33+00:00

Currently, LTO:toolchain-clang is defined using the immediate assignment operator (=). This forces the variable to the default value defined in the class, preventing users from overriding LTO flags for the clang toolchain via distro configuration or local.conf. Change the assignment to use the conditional assignment operator (?=). This ensures that if LTO:toolchain-clang is already set (e.g., in a distro include file), the custom value is preserved and not overwritten by the default. Signed-off-by: mark.yang

clang.bbclass: add clang-native to BASE_DEFAULT_DEPS

2025-12-12T04:21:48+00:00

Add it for target builds in: BASE_DEFAULT_DEPS:append:class-target:toolchain-clang:class-target because ${MLPREFIX}clang-cross-${TARGET_ARCH} contains a broken symlink to clang binary provided by clang-native and then in case someone changes e.g. TC_CXX_RUNTIME = "llvm" to TC_CXX_RUNTIME:class-target = "llvm" then both clang-native and clang-cross-${TARGET_ARCH} are correctly rebuilt, but unfortunately the hashequiv output hash of clang-cross-${TARGET_ARCH} doesn't change (because the broken symlink is still the same), so e.g. gptfdisk which depends on "equivalent" clang-cross from BASE_DEFAULT_DEPS doesn't get rebuilt, but then it still links with libc++.so.1 while in clean build without sstate and hashequiv it will link with libstdc++.so.6 (because TC_CXX_RUNTIME affects only clang-native and the override for class-target doesn't work as one might expect). This might need some bigger changes in hashequiv to have special handlink of broken symlinks in the output, if the symlink target is provided by some dependency, we should include the hash of the symlink target to make sure the outhash changes even when something deeper in dependency tree changed the target binary (or error out when there is no direct dependency of the provider). clang-cross from oe-core master doesn't have this issue, because it contains the actual binary from clang-native after: https://github.com/openembedded/openembedded-core/commit/3b0128fe6421e64674fd250e0b4e6afb1c8ce436 so the outhash is changed when this binary is changed. Signed-off-by: Martin Jansa

bpftrace 0.20.1: Fix CVE-2024-2313

2025-12-12T04:21:23+00:00

Upstream Repository: https://github.com/bpftrace/bpftrace.git Bug Details: https://nvd.nist.gov/vuln/detail/CVE-2024-2313 Type: Security Fix CVE: CVE-2024-2313 Score: 2.8 Patch: https://github.com/bpftrace/bpftrace/commit/bc73244963f2 Note: - This CVE was initially addressed via commit 4be4b7191acb [1], which added ownership verification for unpacked kernel headers. - The fix was deemed insufficient and a revised comprehensive fix was implemented in commit bc73244963f2 [2], which completely removes the risky functionality. - This patch applies only the revised fix (bc73244963f2) which supersedes the initial partial fix. Reference: [1] https://github.com/bpftrace/bpftrace/pull/3033 [2] https://github.com/bpftrace/bpftrace/pull/3156 Signed-off-by: Deepak Rathore

layer.conf: fix LLVMVERSION

2025-12-12T04:20:39+00:00

The llvm/clang was upgraded to 18.1.8 in: https://github.com/kraj/meta-clang/commit/731488911f55ebfe746068512b426351192f82f2 but the variable wasn't updated at the same time. Signed-off-by: Martin Jansa

llvm,clang: update to 18.1.8

2025-10-01T16:54:22+00:00

This is probably the last 18.1.x release, so let's get it in. 3b5b5c1ec4a3 (tag: llvmorg-18.1.8, origin/release/18.x) [libcxx] Align `__recommend() + 1` by __endian_factor (#90292) 72c9425a79fd [libc++][NFC] Rewrite function call on two lines for clarity (#79141) 443e23eed24d Bump version to 18.1.8 (#95458) 768118d1ad38 (tag: llvmorg-18.1.7) [clang-format] Fix a bug in formatting goto labels in macros (#92494) 8c0fe0d65ed8 release/18.x: [clang-format] Don't always break before << between str… (#94091) 7e6ece9b4f2d [PPCMergeStringPool] Only replace constant once (#92996) 1ce2d26cd2e9 Bump version to 18.1.7 (#93723) Signed-off-by: Adrian Freihofer

bpftool: Use gcc instead of clang compiler

2025-09-05T16:12:33+00:00

While compiling bpftool with clang, it fails with below error: | error: no member named 'id' in 'struct bpf_link' | return BPF_CORE_READ((struct bpf_link *)ent, id); bpftool is kernel tool to inspect and manipulate eBPF programs and maps. And kernel is built using GCC by default. Maintaining compatibility with Clang is an ongoing challenge, and using Clang solely for building bpftool is ineffective unless the entire kernel is compiled with Clang. Hence, updated TOOLCHAIN of bpftool to gcc. Signed-off-by: Deepak Rathore

perf: Use gcc as default compiler

2025-08-28T16:48:56+00:00

Since its being build from kernel sources which are procecced with gcc by default KERNEL_CC is gcc, its a constant battle to keep this compiling with clang, so unless clang is also used to compile kernel this is a fruitless excercise to use clang just for perf. Signed-off-by: Khem Raj (cherry picked from commit 9fadcead4fd4336783ef270a4019e105a270daf4) Signed-off-by: Deepak Rathore

clang: fix native build with gcc-15

2025-08-18T15:51:51+00:00

Signed-off-by: Martin Jansa

compiler-rt-sanitizers: disable builtins library

2025-07-10T21:22:52+00:00

Currently compiler-rt-sanitizers fails to build as native recipe. Configuration log shows: -- Compiler-RT supported architectures: x86_64 -- Failed to find compiler-rt builtins library for x86_64-linux The reasons is that calling clang --rtlib=compiler-rt -print-libgcc-file-name returns (tested in devtool and via additional cmake logs) /usr/lib/clang/18.1.6/lib/linux/libclang_rt.builtins-x86_64.a which is missing the recipe-sysroot-native prefix. COMPILER_RT_USE_BUILTINS_LIBRARY=OFF is implemented in kirkstone and also in master (in core). Note that when moving clang from meta-clang to core, I didn't find explanation why this was changed back, but I assume that it was because of issues like this. When running clang --rtlib=compiler-rt -print-libgcc-file-name on master, it correctly returns the sysroot prefix. However re-enabling builtins still results in a failure because on my system it also detects i386 multilib which then fails. Alternative which works (at least in Debian 11) is following: EXTRA_OECMAKE:append:class-native = "\ -DCOMPILER_RT_LIBRARY_builtins_${BUILD_SYS}=${STAGING_LIBDIR_NATIVE}/clang/${PV}/lib/linux/libclang_rt.builtins-${BUILD_ARCH}.a \ -DCOMPILER_RT_LIBRARY_builtins_=${STAGING_LIBDIR_NATIVE}/clang/${PV}/lib/linux/libclang_rt.builtins-${BUILD_ARCH}.a \ " However seeing failures on master, it's uncertain if it fixes all corner cases. Signed-off-by: Peter Marko