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