This patch is intended for recipes that use the bfd linker instead of the lld linker when using LTO in a clang environment.

In Yocto scarthgap, this option was enabled, allowing LTO to be used even when using clang + LTO + bfd linker.
While the lld linker does not require a plugin, the following plugins are required when using the bfd linker.
LLVMgold.so, libLTO.so

We can reproduce the build by adding the following options to your local.conf:
PREFERRED_TOOLCHAIN_TARGET = "clang"
DISTRO_FEATURES:append = " ld-is-lld"
require conf/distro/include/lto.inc
DISTRO_FEATURES:append = " lto"
# The settings below were taken from meta-clang.
LTO:toolchain-clang:class-target = "${@bb.utils.contains('DISTRO_FEATURES', 'thin-lto', '-flto=thin', '-flto -fuse-ld=lld', d)}"
LTO:toolchain-clang:class-nativesdk = "${@bb.utils.contains('DISTRO_FEATURES', 'thin-lto', '-flto=thin', '-flto -fuse-ld=lld', d)}"

For example, components such as zlib force the use of the bfd linker. (https://github.com/openembedded/openembedded-core/commit/be5856616aee1d2134e6aedefc5fe664ad5e2a7d)
In this case, it causes the following error when building zlib: (https://errors.yoctoproject.org/Errors/Details/895736/)
usr/bin/aarch64-oe-linux/../lib/LLVMgold.so: cannot open shared object file: No such file or directory
`/usr/bin/lib/LLVMgold.so` is a very strange path, but this is an issue to be investigated further later. (This occurs because the clang binary is located in `/usr/bin/aarch64-oe-linux`, and the plugin searches for it using a relative path from clang's current location.)

In fact, LLVMgold.so does not exist in the sysroot.
bitbake/bitbake-builds/oe-nodistro-master-nodistro-machine_qemuarm64/build/tmp/sysroots-components $ find ./ -name "*LLVMgold*"
# nothing
bitbake/bitbake-builds/oe-nodistro-master-nodistro-machine_qemuarm64/build/tmp/sysroots-components $ find ./ -name "*libLTO*"
# nothing

To produce this, the following configuration is required in the llvm recipe.
DEPENDS += "binutils"
EXTRA_OECMAKE += "-DLLVM_BINUTILS_INCDIR=${STAGING_INCDIR}"

It existed in the clang recipe for scarthgap, but was omitted in commit https://github.com/openembedded/openembedded-core/commit/d76dc362c8e18779cc4ddc6a778fb423c0e66a65.
It seems this was missed during the process of streamlining the clang build and separating the clang and llvm recipes.
 
However, the following configuration already exists in llvm_git.bb.
70: PACKAGECONFIG:remove:class-native = "lto thin-lto"
81: PACKAGECONFIG[lto] = "-DLLVM_ENABLE_LTO=Full -DLLVM_BINUTILS_INCDIR=${STAGING_INCDIR},,binutils,"
82: PACKAGECONFIG[thin-lto] = "-DLLVM_ENABLE_LTO=Thin -DLLVM_BINUTILS_INCDIR=${STAGING_INCDIR},,binutils,"

The `lto` and `thin-lto` settings in `PACKAGECONFIG` determine whether LTO (Link Time Optimization) will be applied to LLVM itself.
Furthermore, for `llvm-native`, `lto` or `thin-lto` settings in `PACKAGECONFIG` are never applied because they are explicitly removed.
PACKAGECONFIG:remove:class-native = "lto thin-lto" was added in https://github.com/openembedded/openembedded-core/commit/d76dc362c8e18779cc4ddc6a778fb423c0e66a65.
It seems that the use of LTO for LLVM/Clang itself is being avoided to reduce the increase in build time, which is a known disadvantage of LTO.

Even if LLVM/Clang itself does not use LTO, I want to enable LTO for components that are built using LLVM/Clang.
Therefore, providing the necessary tools (LLVMgold.so, libLTO.so) in the sysroot seems appropriate.
 
Building with this configuration will provide the following files in the sysroot:
bitbake/bitbake-builds/oe-nodistro-master-nodistro-machine_qemuarm64/build/tmp/sysroots-components $ find . -name "*LLVMgold*"
./x86_64/llvm-native/usr/lib/LLVMgold.so
bitbake/bitbake-builds/oe-nodistro-master-nodistro-machine_qemuarm64/build/tmp/sysroots-components $ find . -name "*libLTO*"
./x86_64/llvm-native/usr/lib/libLTO.so.21.1
./x86_64/llvm-native/usr/lib/libLTO.so
Even after this patch, zlib will still fail with an error as it cannot find the path to LLVMgold.so.
However, this should be addressed in a future patch.
As mentioned above, because the clang binary is copied to the usr/bin/aarch64-oe-linux/ location and provided to the sysroot, the relative path used to locate the plugin is incorrect.