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.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#229293):
https://lists.openembedded.org/g/openembedded-core/message/229293
Mute This Topic: https://lists.openembedded.org/mt/117252728/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
