Bug 946887 – media-libs/mesa: please add llvm_slot_19

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Michał Dec 2024-12-25 07:54:53 UTC]

I'm on a system that systematically unmasks whatever version of llvm can be worked with by Firefox, so I've ended up in a situation where mesa would not work because I was on llvm 19 and removed llvm 18. After hacking LLVM_COMPAT with 19 into mesa and recompiling everything seems fine, so it should be fine to propagate this in upstream packages.

Reproducible: Always

Steps to Reproduce:
1. Install llvm 19
2. Uninstall llvm 18 or older or whatever mesa was installed with
3. Try to start any GL application or better yet - restart the entire display manager
Actual Results:  
GL apps won't start and Xorg won't start because mesa is linked against llvm 18, which is missing.

Expected Results:  
Normal packages don't depend on a compiler's specific version and do not experience this kind of problem.

This is a worrying observation that packages can tie themselves to the version of llvm and refuse to work if it gets uninstalled. Imagine if gcc did this.

[Comment 1 Sam James 2024-12-25 08:15:33 UTC]

LLVM is also a library, not just a compiler. While it's reasonable to ask if 19 can be added to Mesa, it is *not* anything to do with the compiler and breaking the dependence there is impossible.

[Comment 2 Sam James 2024-12-25 08:19:41 UTC]

Now, as for the steps to reproduce: this isn't connected at all with whether LLVM_COMPAT has 19 for Mesa.

How did you uninstall LLVM 18? If it was via -C/--unmerge, rather than -c/--depclean, then this is broadly expected (although preserve-libs will often save people here).

What exact errors did you get? The only way I can see this happening is an underspecified dependency on LLVM, but it's unrelated to whether it happens to be 18 or 19.

But the ebuild already should depend on it correctly -- which is the whole reason you filed the bug to begin with?

[Comment 3 Michał Dec 2024-12-25 09:49:59 UTC]

>How did you uninstall LLVM 18?

Through emerge -C.

>although preserve-libs will often save people here

preserve-libs did materialize, but only because <dev-util/spirv-llvm-translator-19.0.0 didn't have unstable keywords. Once I accepted ~amd64 keyword for dev-util/spirv-llvm-translator-19.1.2 and compiled this package, preserve-libs was satisfied and would not make itself known during emerge operations. If this was meant to include media-libs/mesa as well, then it has not in my case unfortunately.

>What exact errors did you get?

Upon trying to start Darkplaces, Counter-Strike 1.6, or any other OpenGL application, I would get varying messages about:
- not being able to initialize video modes
- not being able to do anything with GLX

I thought I had just run the computer for too long and some strange memory leak disabled my capacity to do any GL stuff, so I rebooted my computer. lightdm wouldn't start, so I had a look in the Xorg logs. Every video driver for Xorg that I had, was complaining for the exact same reason: cannot find libLLVM-18.so

So my first instinct was to collect all the complaining drivers from the log, ask equery which packages they belong to, and recompile them. The problem persisted, so I had a random guess that it could be another part of the graphic stack that isn't so very obvious for Xorg, but absolutely instrumental for my display manager - media-libs/mesa. There was no version of media-libs/mesa with LLVM_COMPAT including 19, so I hacked it into media-libs/mesa-24.2.8, recompiled and restarted the display-manager service. Everything was fine now.

>But the ebuild already should depend on it correctly -- which is the whole reason you filed the bug to begin with?

Well, if it uses it, it's alright I guess. It's like asking a child do you like going to school. I do this because I have to, because without this giant dependency there's no AMDGPU, Thunderbird, Firefox and OpenCL - not because I like to. What could definitely be improved is the fact that media-libs/mesa managed to evade preserved-libs after uninstalling the version of llvm it depended on. The sole reason I filed this ticket is because I would like to see llvm 19 added to the LLVM_COMPAT list in current ebuilds of media-libs/mesa, to prevent users from running into the same issue.

>LLVM is also a library, not just a compiler. While it's reasonable to ask if 19 can be added to Mesa, it is *not* anything to do with the compiler and breaking the dependence there is impossible.

Thank you for the explanation. It is duly noted.

[Comment 4 Sam James 2024-12-25 10:04:23 UTC]

(In reply to Michał Dec from comment #3)
> >How did you uninstall LLVM 18?
> 
> Through emerge -C.

Please don't ever use -C / --unmerge. It'll rip things out even if something still depends on it. And it should always get pulled back in afterwards (or that thing was depcleanable anyway).

> 
> >although preserve-libs will often save people here
> 
> preserve-libs did materialize, but only because
> <dev-util/spirv-llvm-translator-19.0.0 didn't have unstable keywords. Once I
> accepted ~amd64 keyword for dev-util/spirv-llvm-translator-19.1.2 and
> compiled this package, preserve-libs was satisfied and would not make itself
> known during emerge operations. If this was meant to include media-libs/mesa
> as well, then it has not in my case unfortunately.
> 

This is interesting. I wonder if it's to do with libglvnd indirection or something. I'll keep an eye out for this and have a think.

> >What exact errors did you get?
> 
> Upon trying to start Darkplaces, Counter-Strike 1.6, or any other OpenGL
> application, I would get varying messages about:
> - not being able to initialize video modes
> - not being able to do anything with GLX
> 
> I thought I had just run the computer for too long and some strange memory
> leak disabled my capacity to do any GL stuff, so I rebooted my computer.
> lightdm wouldn't start, so I had a look in the Xorg logs. Every video driver
> for Xorg that I had, was complaining for the exact same reason: cannot find
> libLLVM-18.so
> 
> So my first instinct was to collect all the complaining drivers from the
> log, ask equery which packages they belong to, and recompile them. The
> problem persisted, so I had a random guess that it could be another part of
> the graphic stack that isn't so very obvious for Xorg, but absolutely
> instrumental for my display manager - media-libs/mesa. There was no version
> of media-libs/mesa with LLVM_COMPAT including 19, so I hacked it into
> media-libs/mesa-24.2.8, recompiled and restarted the display-manager
> service. Everything was fine now.
> 
> >But the ebuild already should depend on it correctly -- which is the whole reason you filed the bug to begin with?
> 
> Well, if it uses it, it's alright I guess. It's like asking a child do you
> like going to school. I do this because I have to, because without this
> giant dependency there's no AMDGPU, Thunderbird, Firefox and OpenCL - not
> because I like to. What could definitely be improved is the fact that
> media-libs/mesa managed to evade preserved-libs after uninstalling the
> version of llvm it depended on. The sole reason I filed this ticket is
> because I would like to see llvm 19 added to the LLVM_COMPAT list in current
> ebuilds of media-libs/mesa, to prevent users from running into the same
> issue.

Yeah, understood & fair enough of course. FWIW, the situation has at least got a bit better with llvm-r1.eclass (that was part of the design of it) where we stopped relying on any-of deps which are hard to control, and moved to LLVM_TARGET which means at least users can specify which LLVM they want out of a range.

So in theory at least if you wanted, a lot of the time you should be able to say "please, only 18 for now, given not everything on my system supports 19", but not everything is ported to llvm-r1.eclass yet.

[Comment 5 Mart Raudsepp 2024-12-25 15:47:12 UTC]

To my knowledge tessellation is known to be broken with llvm-19 for mesa until https://gitlab.freedesktop.org/mesa/mesa/-/commit/bd89279dd4c0470620ba8574638235a5bd4d966e (from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32595 but eventually merged via https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32529 ).
This is not in any release yet, so if my information is correct (please someone knowledgeable double-check, I heard it from Alyssa before it was merged, maybe something turned out to be different since then or maybe it applies only to asahi drivers), it would allow only live 9999 ebuild to have llvm-19 as supported.

[Comment 6 Michał Dec 2024-12-26 10:09:54 UTC]

Is there any tesselation demo I can try to see how badly broken things get? I've encountered so far only 2 issues, but I'm not sure these are related.

[Comment 7 Boris Staletic 2024-12-30 21:10:11 UTC]

> > >although preserve-libs will often save people here
> > 
> > preserve-libs did materialize, but only because
> > <dev-util/spirv-llvm-translator-19.0.0 didn't have unstable keywords. Once I
> > accepted ~amd64 keyword for dev-util/spirv-llvm-translator-19.1.2 and
> > compiled this package, preserve-libs was satisfied and would not make itself
> > known during emerge operations. If this was meant to include media-libs/mesa
> > as well, then it has not in my case unfortunately.
> > 

> This is interesting. I wonder if it's to do with libglvnd indirection or something. I'll keep an eye out for this and have a think.

I think this can happen if USE=-llvm and VIDEO_CARDS has none of {lavapipe, radeon, r300}.

[Comment 8 Larry the Git Cow 2024-12-31 20:29:09 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3c0b4a10435fe8fc45ff51d4818268779cd7f50b

commit 3c0b4a10435fe8fc45ff51d4818268779cd7f50b
Author:     Matt Turner <[e-mail]>
AuthorDate: 2024-12-31 20:05:56 +0000
Commit:     Matt Turner <[e-mail]>
CommitDate: 2024-12-31 20:29:02 +0000

    media-libs/mesa: Add LLVM_SLOT=19
    
    Closes: https://bugs.gentoo.org/946887
    Signed-off-by: Matt Turner <[e-mail]>

 media-libs/mesa/mesa-24.3.2.ebuild | 2 +-
 media-libs/mesa/mesa-9999.ebuild   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)