• [gentoo-dev] Multiple LLVM versions with single sys-devel/lld. How to m

    From Piotr Karbowski@21:1/5 to All on Sat Oct 29 18:10:01 2022
    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)
  • From Matt Turner@21:1/5 to slashbeast@gentoo.org on Sat Oct 29 18:30:01 2022
    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>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piotr Karbowski@21:1/5 to Matt Turner on Sat Oct 29 19:00:01 2022
    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)
  • From Matt Turner@21:1/5 to slashbeast@gentoo.org on Sat Oct 29 21:10:01 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piotr Karbowski@21:1/5 to Matt Turner on Sat Oct 29 22:40:02 2022
    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)
  • From Piotr Karbowski@21:1/5 to Piotr Karbowski on Sat Oct 29 22:40:01 2022
    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)