[gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?

[gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?

[Piotr Karbowski]

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.

Re: [gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?

[Matt Turner]

On Sat, Oct 29, 2022 at 12:01 PM Piotr Karbowski <slashbeast@gentoo.org> wrote:
> 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.

Have you seen these commits?

commit 15aad9556ba01ff38a14775dedd8ee088c27c30f
Author: Michał Górny <mgorny@gentoo.org>
Date:   Fri Oct 14 19:47:20 2022 +0200

    sys-devel/lld: Enable slotting on 13.0.1

    Signed-off-by: Michał Górny <mgorny@gentoo.org>

commit f1a40a736023a8f1be25e478ef657cf4c772306b
Author: Michał Górny <mgorny@gentoo.org>
Date:   Fri Oct 14 17:37:47 2022 +0200

    sys-devel/lld: Enable slotting on 14.0.6

    Signed-off-by: Michał Górny <mgorny@gentoo.org>

commit ea9e70d251dd711b91ac3d6da48ab09ce564f3ea
Author: Michał Górny <mgorny@gentoo.org>
Date:   Fri Oct 14 14:58:56 2022 +0200

    sys-devel/lld: Enable slotting on LLD 15+

    Signed-off-by: Michał Górny <mgorny@gentoo.org>

Re: [gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?

[Piotr Karbowski]

On 29/10/2022 18.22, Matt Turner wrote:
> Have you seen these commits?

I did not, thanks. Seems like the solution. Is there a reason why llvm:N 
do not pull in lld:N in that case?

-- Piotr.

Re: [gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?

[Matt Turner]

On Sat, Oct 29, 2022 at 12:53 PM Piotr Karbowski <slashbeast@gentoo.org> wrote:
>
> On 29/10/2022 18.22, Matt Turner wrote:
> > Have you seen these commits?
>
> I did not, thanks. Seems like the solution. Is there a reason why llvm:N
> do not pull in lld:N in that case?

lld isn't a dependency of llvm; it's the same reason why llvm:N
doesn't depend on clang:N.

Re: [gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?

[Piotr Karbowski]

On 29/10/2022 21.01, Matt Turner wrote:
> lld isn't a dependency of llvm; it's the same reason why llvm:N
> doesn't depend on clang:N.

That's fair. Still a bit of a bummer that we cannot guarantee a 
frictionless support for clang-based kernels, in a sense that your 
system could pull new update of llvm and clang, but will not 
automatically add new slot for lld, which means unless you manually 
install lld:NEW_SLOT your 'make LLVM=1' will fail, as it will pick wrong 
LD from another clang version.

-- Piotr.

Re: [gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to match runtime?

[Piotr Karbowski]

On 29/10/2022 22.35, Piotr Karbowski wrote:
> On 29/10/2022 21.01, Matt Turner wrote:
>> lld isn't a dependency of llvm; it's the same reason why llvm:N
>> doesn't depend on clang:N.
> 
> That's fair. Still a bit of a bummer that we cannot guarantee a 
> frictionless support for clang-based kernels, in a sense that your 
> system could pull new update of llvm and clang, but will not 
> automatically add new slot for lld, which means unless you manually 
> install lld:NEW_SLOT your 'make LLVM=1' will fail, as it will pick wrong 
> LD from another clang version.

Disregard, as long as you have lld in world file or any set, it will be 
updated. In my case I only had firefox that explicit pulled in slot 14. 
PEBKAC.

-- Piotr.