Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[Solved] Mesa - LLVM/Clang Multiple Versions
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Weezer
n00b
n00b


Joined: 19 Apr 2024
Posts: 11

PostPosted: Fri May 24, 2024 1:21 pm    Post subject: [Solved] Mesa - LLVM/Clang Multiple Versions Reply with quote

Greetings!

Within the last day or so, it appears Mesa is now pulling in Clang when the LLVM use flag is enabled (in Mesa). I hadn't needed LLVM until recently (still trying to figure that out) and now Clang is being pulled in. I have read that THAT is due to changes in Mesa (intel_clc).

Code:
→ emerge -capv llvm

Calculating dependencies                             ... done!     
  sys-devel/llvm-17.0.6 pulled in by:
    dev-util/intel_clc-24.1.0 requires sys-devel/llvm:17
    dev-util/spirv-llvm-translator-17.0.0-r2 requires sys-devel/llvm:17=, sys-devel/llvm:17/17=
    media-libs/mesa-24.1.0-r1 requires sys-devel/llvm:17[llvm_targets_AMDGPU(+),abi_x86_64(-)]
    sys-devel/clang-17.0.6 requires ~sys-devel/llvm-17.0.6[llvm_targets_AArch64], ~sys-devel/llvm-17.0.6[llvm_targets_X86], ~sys-devel/llvm-17.0.6[llvm_targets_VE], ~sys-devel/llvm-17.0.6:17/17=[-debug,abi_x86_64(-)], ~sys-devel/llvm-17.0.6[llvm_targets_Hexagon], ~sys-devel/llvm-17.0.6[llvm_targets_Lanai], ~sys-devel/llvm-17.0.6[llvm_targets_Sparc], ~sys-devel/llvm-17.0.6[llvm_targets_BPF], ~sys-devel/llvm-17.0.6[llvm_targets_RISCV], ~sys-devel/llvm-17.0.6[llvm_targets_XCore], ~sys-devel/llvm-17.0.6[llvm_targets_ARM], ~sys-devel/llvm-17.0.6[llvm_targets_WebAssembly], ~sys-devel/llvm-17.0.6:17=[-debug,abi_x86_64(-)], ~sys-devel/llvm-17.0.6[llvm_targets_NVPTX], ~sys-devel/llvm-17.0.6[llvm_targets_PowerPC], ~sys-devel/llvm-17.0.6[llvm_targets_SystemZ], ~sys-devel/llvm-17.0.6[llvm_targets_AVR], ~sys-devel/llvm-17.0.6[llvm_targets_Mips], ~sys-devel/llvm-17.0.6[llvm_targets_AMDGPU], ~sys-devel/llvm-17.0.6[llvm_targets_MSP430], ~sys-devel/llvm-17.0.6[llvm_targets_LoongArch]
    sys-devel/llvm-toolchain-symlinks-17 requires sys-devel/llvm:17
    sys-libs/compiler-rt-17.0.6 requires sys-devel/llvm:17
    sys-libs/compiler-rt-sanitizers-17.0.6 requires sys-devel/llvm:17

  sys-devel/llvm-18.1.6 pulled in by:
    sys-devel/clang-18.1.6 requires ~sys-devel/llvm-18.1.6[llvm_targets_X86], ~sys-devel/llvm-18.1.6[llvm_targets_XCore], ~sys-devel/llvm-18.1.6[llvm_targets_SystemZ], ~sys-devel/llvm-18.1.6[llvm_targets_ARM], ~sys-devel/llvm-18.1.6:18/18.1=[-debug,abi_x86_64(-)], ~sys-devel/llvm-18.1.6[llvm_targets_BPF], ~sys-devel/llvm-18.1.6[llvm_targets_Sparc], ~sys-devel/llvm-18.1.6[llvm_targets_AVR], ~sys-devel/llvm-18.1.6[llvm_targets_Mips], ~sys-devel/llvm-18.1.6[llvm_targets_Hexagon], ~sys-devel/llvm-18.1.6:18=[-debug,abi_x86_64(-)], ~sys-devel/llvm-18.1.6[llvm_targets_Lanai], ~sys-devel/llvm-18.1.6[llvm_targets_WebAssembly], ~sys-devel/llvm-18.1.6[llvm_targets_LoongArch], ~sys-devel/llvm-18.1.6[llvm_targets_RISCV], ~sys-devel/llvm-18.1.6[llvm_targets_NVPTX], ~sys-devel/llvm-18.1.6[llvm_targets_VE], ~sys-devel/llvm-18.1.6[llvm_targets_MSP430], ~sys-devel/llvm-18.1.6[llvm_targets_AMDGPU], ~sys-devel/llvm-18.1.6[llvm_targets_AArch64], ~sys-devel/llvm-18.1.6[llvm_targets_PowerPC]
    sys-devel/llvm-toolchain-symlinks-18 requires sys-devel/llvm:18
    sys-devel/llvmgold-18 requires sys-devel/llvm:18[binutils-plugin]
    sys-libs/compiler-rt-18.1.6 requires sys-devel/llvm:18
    sys-libs/compiler-rt-sanitizers-18.1.6 requires sys-devel/llvm:18


I should iterate that I'm on Gentoo unstable.

I'm not complaining here, but looking for a solution as this machine is 'older' and emerge times are quite long.

Mesa always seems to need an older (stable) version of LLVM, in this case LLVM:17, and because I'm on unstable, LLVM:18 gets pulled in as well. Now, both versions of Clang are getting pulled in amongst other depends. It took this machine approximately 12 hours for Clang to emerge (both versions)...and LLVM around 4 hours each when it is needed (all approximations).

Is there a good way to stop LLVM/Clang unstable from emerging as I truly only need one version of LLVM/Clang (corresponding to Mesa dependencies)?

Can I change the Mesa ebuild to target LLVM:18?

Should I mask all packages related to LLVM/Clang:18 (seems messy).

Would setting LLVM/Clang accept keywords to 'amd64' work (also messy if it would even work)?

Should I just forget about it (easiest)?

I definitely know this has come up in the past and the answer seems to usually be "wait for Mesa to catch up", paraphrasing, but Mesa doesn't seem to catch up. It is a bit painful to have one use flag result in multiple large merge time packages that now includes Clang, along with LLVM.

I know this may be an exercise in futility, but any suggestions would be greatly appreciated!

Thanks much in advance.


Last edited by Weezer on Sat May 25, 2024 12:02 pm; edited 2 times in total
Back to top
View user's profile Send private message
grknight
Retired Dev
Retired Dev


Joined: 20 Feb 2015
Posts: 1744

PostPosted: Fri May 24, 2024 1:32 pm    Post subject: Reply with quote

See also media-libs/mesa-24.1.0 pulls llvm/clang for why this happens to those with Intel video cards.

Note that it is not just mesa but also dev-util/intel_clc that is maxed at LLVM:17 at this time.
Back to top
View user's profile Send private message
Weezer
n00b
n00b


Joined: 19 Apr 2024
Posts: 11

PostPosted: Fri May 24, 2024 1:57 pm    Post subject: Reply with quote

grknight wrote:
See also media-libs/mesa-24.1.0 pulls llvm/clang for why this happens to those with Intel video cards.

Note that it is not just mesa but also dev-util/intel_clc that is maxed at LLVM:17 at this time.


Noted - I believe media-libs/mesa-24.1.0 is what pulled in dev-util/intel_clc for me...
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 21918

PostPosted: Fri May 24, 2024 2:42 pm    Post subject: Reply with quote

Unstable tends to see more updates than stable, so if building large packages is a burden, you may want to stick to stable for its rarer updates.

You could certainly try using a per-package keyword override to discourage use of the newer clang/llvm. However, this may not be well tested, and could be broken now or break unexpectedly later. I cannot comment on whether this will build for you today, or how likely it is to remain working.

If it were me, I would pick the keyword change over tinkering with the ebuilds. It is easier to write and requires no ongoing maintenance (assuming it works at all).

To implement this (untested):
/etc/portage/package.accept_keywords:
sys-devel/clang -~amd64 amd64
sys-devel/llvm -~amd64 amd64
You may need to add more packages to this list, such as clang-common or clang-runtime.
Back to top
View user's profile Send private message
Weezer
n00b
n00b


Joined: 19 Apr 2024
Posts: 11

PostPosted: Fri May 24, 2024 4:52 pm    Post subject: Reply with quote

Hu wrote:
Unstable tends to see more updates than stable, so if building large packages is a burden, you may want to stick to stable for its rarer updates.


I absolutely cannot do that... ;) I've one laptop running stable and it is zero fun. I'm simply trying to avoid doubling up on these.

Hu wrote:
If it were me, I would pick the keyword change over tinkering with the ebuilds. It is easier to write and requires no ongoing maintenance (assuming it works at all).

To implement this (untested):
/etc/portage/package.accept_keywords:
sys-devel/clang -~amd64 amd64
sys-devel/llvm -~amd64 amd64
You may need to add more packages to this list, such as clang-common or clang-runtime.


Thanks for this. I will probably try just to see how big the rabbit hole is (then reverse everything and live with it).

Will close after watching for a bit.
Back to top
View user's profile Send private message
Weezer
n00b
n00b


Joined: 19 Apr 2024
Posts: 11

PostPosted: Sat May 25, 2024 12:01 pm    Post subject: Reply with quote

I was able to successfully remove sys-devel/clang:18 and sys-devel/llvm:18 and all associated packages via package.accept_keywords with:

Code:
sys-devel/clang -~amd64 amd64
sys-devel/llvm -~amd64 amd64
sys-devel/llvmgold -~amd64 and64
sys-devel/llvm-common -~amd64 amd64
sys-libs/libomp -~amd64 amd64


Resulting in only stable versions left on my system.

Code:
→ emerge -capv llvm

Calculating dependencies ... done!               
  sys-devel/llvm-17.0.6 pulled in by:
    dev-util/intel_clc-24.1.0 requires sys-devel/llvm:17
    dev-util/spirv-llvm-translator-17.0.0-r2 requires sys-devel/llvm:17=, sys-devel/llvm:17/17=
    media-libs/mesa-24.1.0-r1 requires sys-devel/llvm:17[llvm_targets_AMDGPU(+),abi_x86_64(-)]
    sys-devel/clang-17.0.6 requires ~sys-devel/llvm-17.0.6[llvm_targets_Sparc], ~sys-devel/llvm-17.0.6[llvm_targets_PowerPC], ~sys-devel/llvm-17.0.6[llvm_targets_BPF], ~sys-devel/llvm-17.0.6[llvm_targets_WebAssembly], ~sys-devel/llvm-17.0.6[llvm_targets_MSP430], ~sys-devel/llvm-17.0.6[llvm_targets_AVR], ~sys-devel/llvm-17.0.6:17=[-debug,abi_x86_64(-)], ~sys-devel/llvm-17.0.6[llvm_targets_Mips], ~sys-devel/llvm-17.0.6[llvm_targets_LoongArch], ~sys-devel/llvm-17.0.6[llvm_targets_RISCV], ~sys-devel/llvm-17.0.6[llvm_targets_AArch64], ~sys-devel/llvm-17.0.6[llvm_targets_Hexagon], ~sys-devel/llvm-17.0.6[llvm_targets_VE], ~sys-devel/llvm-17.0.6:17/17=[-debug,abi_x86_64(-)], ~sys-devel/llvm-17.0.6[llvm_targets_ARM], ~sys-devel/llvm-17.0.6[llvm_targets_SystemZ], ~sys-devel/llvm-17.0.6[llvm_targets_AMDGPU], ~sys-devel/llvm-17.0.6[llvm_targets_NVPTX], ~sys-devel/llvm-17.0.6[llvm_targets_XCore], ~sys-devel/llvm-17.0.6[llvm_targets_Lanai], ~sys-devel/llvm-17.0.6[llvm_targets_X86]
    sys-devel/llvm-toolchain-symlinks-17 requires sys-devel/llvm:17
    sys-devel/llvmgold-17 requires sys-devel/llvm:17[binutils-plugin]
    sys-libs/compiler-rt-17.0.6 requires sys-devel/llvm:17
    sys-libs/compiler-rt-sanitizers-17.0.6 requires sys-devel/llvm:17



Clang needed the single entry and took care of itself. LLVM was a bit more finicky and I needed to add sys-devel/llvmgold, sys-devel/llvm-common and sys-libs/libomp in order to maintain consistent versions.

Not sure how it will go in the future but the desired effect is one version of LLVM/Clang each along with associated packages that correspond with media-libs/mesa-24.1.0-r1.

A bit of a mixed system but it's okay in my mind as this is needed for only mesa atm (and intel_clc).

Thanks Hu for your input/assistance, it is appreciated!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum