Hi,
The state for this very moment is that we can have many versions of llvm
around, however we can at most have only one ld.lld installed. Usually
matching the lowest version of clang installed.
THis leads to build failures if one attempts to build some (but not all)
software, Linux kernel being one of them.
Currently if one have installed clang in 15 and 14 version, and ld.lld
in 14, and attempt to build Linux kernel with simple 'make LLVM=1' it
will fail on the mismatch between clang and ld.lld with "Opaque pointers
are only supported in -opaque-pointers mode".
This can be easily handled by doing 'make LLVM=1 CC=clang-14'.
Now, the problem is with kernel modules that are in ::gentoo. One of the
examples is ryzen_smu that has github's PR to support kernels built with
clang and lto enabled.
I might be not really up to the speed with llvm in gentoo, but it
appears to me we have no interface to get matching clang+lld paths that
could be callable like ts-getCC is. Setting CC=${CHOST}-clang when
kernel's config has LLVM toggled will result in crash due to ld.lld
mismatch, easy workaround would be to set $PATH before calling emerge so
it would first find the matching 14 version, however emerge will build
its own $PATH, ignoring whatever we provided there.
Which means one would either need to write a code in ebuild to get lld
version and then set CC to ${CHOST}-clang-${LLD_MAJOR_VERSION} or have
similar code in /etc/portage/bashrc, neither of which are particularly
appealing to me even though it's rather simple to get the version out of
ld.lld.
Before I invent such a atrocious code in ebuild, do you perhaps have any
solution that is somewhat more reasonable than ebuild doing backflips to
figure out working toolchain combination?
-- Piotr.
