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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Oct 29, 2022 at 12:01 PM Piotr Karbowski <[email protected]> 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 <[email protected]>
Date: Fri Oct 14 19:47:20 2022 +0200

sys-devel/lld: Enable slotting on 13.0.1

Signed-off-by: Michał Górny <[email protected]>

commit f1a40a736023a8f1be25e478ef657cf4c772306b
Author: Michał Górny <[email protected]>
Date: Fri Oct 14 17:37:47 2022 +0200

sys-devel/lld: Enable slotting on 14.0.6

Signed-off-by: Michał Górny <[email protected]>

commit ea9e70d251dd711b91ac3d6da48ab09ce564f3ea
Author: Michał Górny <[email protected]>
Date: Fri Oct 14 14:58:56 2022 +0200

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

Signed-off-by: Michał Górny <[email protected]>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Oct 29, 2022 at 12:53 PM Piotr Karbowski <[email protected]> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)