VAR:append:<OVERRIDES> is the right way to use it

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Signed-off-by: Jan Vermaete <jan.vermaete@gmail.com>

Signed-off-by: Jan Kircher <jan.kircher@leica-microsystems.com>

glibc static library expects builtins from libgcc which may not exist
in compiler-rt, therefore use libgcc explicitly.

Now that static is enabled by default in packageconfig

Fix is taken from [1]

[1] https://github.com/foundriesio/meta-lmp/commit/0abb08c83aee7027711f538e29a5ff16dc334304



Signed-off-by: Khem Raj <raj.khem@gmail.com>

libc++ seems to result in test failures, perhaps something to fix
in toml++ but it needs to be triaged.

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Release has changes as mentioned in [1] and [2]

[1] https://discourse.llvm.org/t/llvm-19-1-1-released/82321
[2] https://discourse.llvm.org/t/llvm-19-1-2-released/82550



Signed-off-by: Khem Raj <raj.khem@gmail.com>

llvm-project-source.inc: fix racing on building lib32-llvm-project-source-19.1.0 and llvm-project-source-19.1.0

While enabling multilib, build lib32-llvm-project-source-19.1.0 and
llvm-project-source-19.1.0 at the same time:

    $ MACHINE = "qemux86-64"
    $ require conf/multilib.conf
    $ MULTILIBS = "multilib:lib32"
    $ DEFAULTTUNE:virtclass-multilib-lib32 = "x86"
    $ bitbake lib32-llvm-project-source-19.1.0 llvm-project-source-19.1.0
    ...
    $ cat tmp/work-shared/llvm-project-source-19.1.0-r0/temp/log.task_order
    20241012-070604.819630 do_recipe_qa (2728706): log.do_recipe_qa.2728706
    20241012-070604.883194 do_recipe_qa (2728707): log.do_recipe_qa.2728707
    20241012-070605.037448 do_fetch (2728779): log.do_fetch.2728779
    20241012-070605.165280 do_fetch (2728848): log.do_fetch.2728848
    20241012-071030.798104 do_unpack (2733554): log.do_unpack.2733554
    20241012-071030.864536 do_unpack (2733559): log.do_unpack.2733559

There are two tasks for do_fetch, do_unpack and others, so there are race issues.

Both of them have the same hardcode 'llvm-project-source-' prefix in ${WORKDIR} and
${S}, explicitly disable lib32-llvm-project-source-19.1.0 for multilib

Set llvm-project-source as BPN of llvm-project-source-19.1.0

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>

Signed-off-by: Khem Raj <raj.khem@gmail.com>

it uses its own linker wrapper which calls LD variable in the end
and expects it to be traditional GNU linker. Lets provide it
what it needs.

Signed-off-by: Khem Raj <raj.khem@gmail.com>

When ld-is-lld is in DISTRO_FEATURE, user wants to use lld as system
linker, therefore honor the setting for bare linker as well, for compiler
its being taken care by clang itself using -fuse-ld=lld

Signed-off-by: Khem Raj <raj.khem@gmail.com>

This creates a problem when swapping linkers, it
does not work without cleaning the recipe first,
in anycase if we want to use lld as default in clang
then it should be done during clang compile

Add packageconfig to let clang defualt

Signed-off-by: Khem Raj <raj.khem@gmail.com>

This reverts commit d1793483.

Trivial fix for a typo in the LIBCPLUSPLUS examples.

Signed-off-by: Pablo Saavedra <psaavedra@igalia.com>

It needs to use BFD linker

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Since clang is at version 19 now, remove the blocking of building
u-boot.  I'm not seeing any issues with building u-boot and running
testimage for qemuarm, qemuarm64, and qemumips.
Based on the original comment, this limitation probably should've been
only applied to mips.

Leaving the BSP versions of u-boot in nonclangable, as I don't know if
those have issues or not, and thought it better to err on the side of
caution.

Signed-off-by: Jon Mason <jdmason@kudzu.us>

This issue has been resolved upstream:

https://gitlab.gnome.org/GNOME/vte/-/commit/c8838779d5f8c0e03411cef9775cd8f5a10a6204



This reverts commit 70295d73.

Signed-off-by: Ross Burton <ross.burton@arm.com>

These tools are unmaintained and clang-20+ has removed them [1] [2]

[1] https://github.com/llvm/llvm-project/commit/ed8f78827895050442f544edef2933a60d4a7935
[2] https://github.com/llvm/llvm-project/commit/40c45b6b43180221acb49f387e7d3158adf49e3e



Signed-off-by: Khem Raj <raj.khem@gmail.com>

Somehow clang built binaries used in intermediate step crashes the qemu
user mode.

Signed-off-by: Khem Raj <raj.khem@gmail.com>

It does not build with libc++ anymore.

Signed-off-by: Khem Raj <raj.khem@gmail.com>

This makes the chromium build less confused when mixing
native compiler for gcc and target compiler for clang
this does not sit well with gn build system and it starts
to pass clang options to gcc, which does not always work

Signed-off-by: Khem Raj <raj.khem@gmail.com>

ptest tries to compile some portions on the target
and demands the compiler that was used to cross-compile it

Signed-off-by: Khem Raj <raj.khem@gmail.com>

openmp port for riscv32 is not yet available so we
can not use clang for it for now.

Signed-off-by: Khem Raj <raj.khem@gmail.com>

This is no longer needed with clang-19

Signed-off-by: Khem Raj <raj.khem@gmail.com>

With clang-19 LLDB is building fine for RISCV64

Signed-off-by: Khem Raj <raj.khem@gmail.com>

This is a workaround until [1] is fixed

[1] https://github.com/llvm/llvm-project/issues/108262



Signed-off-by: Khem Raj <raj.khem@gmail.com>

These recipes do not yet build with libc++-19, for now
use libstdc++, poco and netdata do not compile with clang-19
at all

Signed-off-by: Khem Raj <raj.khem@gmail.com>

* other libraries are installed in 'lib64' or 'lib32' based on
  LLVM_LIBDIR_SUFFIX value, but libscanbuild files were always
  installed in 'lib'

* fixes:
  ERROR: QA Issue: lib32-clang: Files/directories were installed but not shipped in any package:
    /usr/lib/libscanbuild
    /usr/lib/libscanbuild/intercept.py
    /usr/lib/libscanbuild/analyze.py
    /usr/lib/libscanbuild/clang.py
    /usr/lib/libscanbuild/report.py
    /usr/lib/libscanbuild/arguments.py
    /usr/lib/libscanbuild/shell.py
    /usr/lib/libscanbuild/compilation.py
    /usr/lib/libscanbuild/__init__.py
    /usr/lib/libscanbuild/resources
    /usr/lib/libscanbuild/resources/sorttable.js
    /usr/lib/libscanbuild/resources/selectable.js
    /usr/lib/libscanbuild/resources/scanview.css
  Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
  lib32-clang: 13 installed and not shipped files. [installed-vs-shipped]

  e.g. in multilib build where libdir is set to /usr/lib32 or /usr/lib64.

Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>

Release Notes below

llvm - https://releases.llvm.org/19.1.0/docs/ReleaseNotes.html
clang - https://releases.llvm.org/19.1.0/tools/clang/docs/ReleaseNotes.html
lld - https://releases.llvm.org/19.1.0/tools/lld/docs/ReleaseNotes.html
libc++ - https://releases.llvm.org/19.1.0/projects/libcxx/docs/ReleaseNotes.html
clang-extra - https://releases.llvm.org/19.1.0/tools/clang/tools/extra/docs/ReleaseNotes.html



Signed-off-by: Khem Raj <raj.khem@gmail.com>

Fixes build with clang-19

Signed-off-by: Khem Raj <raj.khem@gmail.com>

it need to be ported to not use generic char_traits

Signed-off-by: Khem Raj <raj.khem@gmail.com>

* Avoid line statements from bison to fix:
  WARNING: bpftrace-0.21.2+git-r0 do_package_qa: QA Issue: File /usr/src/debug/bpftrace/0.21.2+git/parser.tab.cc in package bpftrace-src contains reference to TMPDIR [buildpaths]
  WARNING: bpftrace-0.21.2+git-r0 do_package_qa: QA Issue: File /usr/src/debug/bpftrace/0.21.2+git/location.hh in package bpftrace-src contains reference to TMPDIR [buildpaths]
  WARNING: bpftrace-0.21.2+git-r0 do_package_qa: QA Issue: File /usr/src/debug/bpftrace/0.21.2+git/parser.tab.hh in package bpftrace-src contains reference to TMPDIR [buildpaths]
  WARNING: bpftrace-0.21.2+git-r0 do_package_qa: QA Issue: File /usr/src/debug/bpftrace/0.21.2+git/lex.yy.cc in package bpftrace-src contains reference to TMPDIR [buildpaths]

* there are still few more buildpaths issues with ptest enabled:
  WARNING: bpftrace-0.21.2+git-r0 do_package_qa: QA Issue: File /usr/src/debug/bpftrace/0.21.2+git/tests/data/dwarf_data.h in package bpftrace-src contains reference to TMPDIR [buildpaths]
  WARNING: bpftrace-0.21.2+git-r0 do_package_qa: QA Issue: File /usr/lib/bpftrace/ptest/tests/.debug/bpftrace_test in package bpftrace-dbg contains reference to TMPDIR [buildpaths]
  WARNING: bpftrace-0.21.2+git-r0 do_package_qa: QA Issue: File /usr/lib/bpftrace/ptest/tests/bpftrace_test in package bpftrace-ptest contains reference to TMPDIR [buildpaths]
  WARNING: bpftrace-0.21.2+git-r0 do_package_qa: QA Issue: File /usr/lib/bpftrace/ptest/tests/testlibs/cmake_install.cmake in package bpftrace-ptest contains reference to TMPDIR [buildpaths]
  WARNING: bpftrace-0.21.2+git-r0 do_package_qa: QA Issue: File /usr/lib/bpftrace/ptest/tests/testlibs/CTestTestfile.cmake in package bpftrace-ptest contains reference to TMPDIR [buildpaths]
  WARNING: bpftrace-0.21.2+git-r0 do_package_qa: QA Issue: File /usr/lib/bpftrace/ptest/tests/testprogs/cmake_install.cmake in package bpftrace-ptest contains reference to TMPDIR [buildpaths]
  WARNING: bpftrace-0.21.2+git-r0 do_package_qa: QA Issue: File /usr/lib/bpftrace/ptest/tests/testprogs/CTestTestfile.cmake in package bpftrace-ptest contains reference to TMPDIR [buildpaths]

* lower buildpaths from ERROR_QA to WARN_QA when ptest is enabled
  fixing .cmake files might be simple, but the embedded path to dwarf_data.h
  in bpftrace_test will be more complicated, so will leave it to
  someone actually using bpftrace (and its ptest).

  bpftrace/0.21.2+git/package $ grep -R styhead .
  ./usr/lib/bpftrace/ptest/tests/testlibs/cmake_install.cmake:# Install script for directory: ${WORKDIR}/git/tests/testlibs
  ./usr/lib/bpftrace/ptest/tests/testlibs/cmake_install.cmake:  set(CMAKE_OBJDUMP "${WORKDIR}/recipe-sysroot-native/usr/bin/aarch64-webos-linux/aarch64-webos-linux-objdump")
  ./usr/lib/bpftrace/ptest/tests/testlibs/CTestTestfile.cmake:# Source directory: ${WORKDIR}/git/tests/testlibs
  ./usr/lib/bpftrace/ptest/tests/testlibs/CTestTestfile.cmake:# Build directory: ${WORKDIR}/build/tests/testlibs
  grep: ./usr/lib/bpftrace/ptest/tests/.debug/bpftrace_test: binary file matches
  grep: ./usr/lib/bpftrace/ptest/tests/bpftrace_test: binary file matches
  ./usr/lib/bpftrace/ptest/tests/testprogs/cmake_install.cmake:# Install script for directory: ${WORKDIR}/git/tests/testprogs
  ./usr/lib/bpftrace/ptest/tests/testprogs/cmake_install.cmake:  set(CMAKE_OBJDUMP "${WORKDIR}/recipe-sysroot-native/usr/bin/aarch64-webos-linux/aarch64-webos-linux-objdump")
  ./usr/lib/bpftrace/ptest/tests/testprogs/CTestTestfile.cmake:# Source directory: ${WORKDIR}/git/tests/testprogs
  ./usr/lib/bpftrace/ptest/tests/testprogs/CTestTestfile.cmake:# Build directory: ${WORKDIR}/build/tests/testprogs
  ./usr/src/debug/bpftrace/0.21.2+git/tests/data/dwarf_data.h:constexpr inline const char *dwarf_data_cxx_path = "${WORKDIR}/build/tests/data/data_source_cxx";

Signed-off-by: Martin Jansa <martin.jansa@gmail.com>

WARNING: bcc-0.30.0+git-r0 do_package_qa: QA Issue: File /usr/lib/bcc/ptest/tests/cc/test_libbcc_no_libbpf in package bcc-ptest contains reference to TMPDIR [buildpaths]

This one is difficult to resolve, because the tests use CMAKE_CURRENT_BINARY_DIR directly in .cc e.g.:
https://github.com/iovisor/bcc/commit/7271bfc946a19413761be2e3c60c48bf72c5eea1#diff-233a0bfa490f3d7466c49935b64c86dd93956bbc0461f5af703b344cf6601461


we would probably need to use separate variable for "runtime" path for test assets from the standard CMAKE_CURRENT_BINARY_DIR variable or use relative
path from the test binary

Signed-off-by: Martin Jansa <martin.jansa@gmail.com>

* bpftrace itself doesn't depend on meta-python, but
  bpftrace from dynamic-layers/openembedded-layer depends on bcc from dynamic-layers/meta-python
  so better to move it there. This way both bcc and bpftrace are either both available
  at the same time or neither of them.

* fixes https://github.com/kraj/meta-clang/issues/985



  ERROR: Nothing PROVIDES 'bcc' (but /mnt/secondary/poky/meta-clang/dynamic-layers/openembedded-layer/recipes-devtools/bpftrace/bpftrace_0.20.1.bb DEPENDS on or otherwise requires it). Close matches:
    bc
    byacc
  NOTE: Runtime target 'bpftrace' is unbuildable, removing...
  Missing or unbuildable dependency chain was: ['bpftrace', 'bcc']
  ERROR: Required build target 'core-image-minimal' has no buildable providers.
  Missing or unbuildable dependency chain was: ['core-image-minimal', 'bpftrace', 'bcc']

  when only openembedded-layer (meta-oe) is in BBLAYERS and meta-python isn't.

Signed-off-by: Martin Jansa <martin.jansa@gmail.com>

Its still needed with clang-18 with libc++

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Brings clang-19 support

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Fix build on upcoming clang-19

Signed-off-by: Khem Raj <raj.khem@gmail.com>

https://github.com/jtv/libpqxx/issues/738 seems to have been fixed
Workaround issue with clang-20 caused by
https://github.com/ARM-software/astc-encoder/commit/8377e52e57c1fb5bcf159aa981f3b25b7bad1cb3



Signed-off-by: Khem Raj <raj.khem@gmail.com>