[bug#49339] [PATCH core-updates] gnu: mesa: Update to 21.1.4.

[John Kehayias]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Friday, July 9th, 2021 at 8:48 AM, Maxime Devos wrote:

> Warning: I've no idea how building mesa and libglvnd works,
>
> how linking against mesa and libglvnd works, and how mesa and libglvnd
>
> work, besides ‘you can use the GL_... functions to do GL stuff’.
>
No worries, I also know very little here (just learning about libglvnd), so I'm 
no expert. However, I think it will be a little more complicated because 
libglvnd is meant to dispatch to a vendor's GL libraries at runtime. Meaning it 
will need to know where these libraries exist, which may require some changes 
for Guix.

> That said, it appears some package definitions expect "libGL.so" to be in 
> mesa.
>
> (Search for "/lib/libGL" and "lib/libEGL" with 'git grep -F"').
>
> I've found about twenty such occurences, including libepoxy.
>
> So it appears that adding libglvnd to the propagated-inputs and fixing
>
> these twenty package definitions should be doable.
>
> Looking at libepoxy in particular:
>
> (let ((python (assoc-ref inputs "python"))
>
> (mesa (assoc-ref inputs "mesa")))
>
> (substitute* "src/gen_dispatch.py"
>
> (("/usr/bin/env python") python))
>
> (substitute* (find-files "." "\\.[ch]$")
>
> (("libGL.so.1") (string-append mesa "/lib/libGL.so.1"))
>
> (("libEGL.so.1") (string-append mesa "/lib/libEGL.so.1")))
>
> #t))))))
>
> it seems like the test failure isn't a false positive, as libGL.so.1 is 
> searched
>
> for in the wrong location.
>
While I think getting builds and tests to pass is not so bad, I don't know that 
it will actually work the way it is supposed to (see above). I'm also a bit 
limited in what I can test directly. (For one thing, I'm on a foreign distro 
right now, which complicates GL testing. For example, Nix has 
https://github.com/guibou/nixGL for the "OpenGL problem" which may be something 
we should look at for this as well.)

> > Anyway, perhaps we want to tackle libglvnd separately? I don't think it is 
> > specific to the Mesa version change, but more of how we want to handle gl 
> > across packages. Still, it will involve changes to how we build Mesa as 
> > well as possibly other packages. I'm not sure that the Mesa version change 
> > will require other changes in dependent packages (I can only test a few on 
> > my own).
> >
> > How do you think we should proceed?
>
> I'd suggest adding libglvnd to propagated-inputs
>
> and adjusting the twenty package definitions to refer
>
> to libglvnd, and testing some graphical applications.
>
> "mesa-utils" has "glxdemo" and "glxheads" and has few dependencies,
>
> maybe start with that?
>
The more I think about it, the more I think we should tackle a change to Guix's 
GL system separately. The original patch enabled libglvnd in Mesa, but that has 
been around for a while and is not new to 21.1.x. I worry doing them at the 
same time would introduce two sources for anything breaking, though I hope the 
move to 21.1.x doesn't require any big changes elsewhere.

Personally, I'd like to see Mesa 21.1.x updated and make sure dependents are 
okay. We can then have a separate patch series that enables libglvnd in Mesa 
and adjusts all packages. We would need some people who can test that actually 
use different GL vendors to see that libglvnd does what it is supposed to. 
Perhaps Irfan can weigh in, since in their original patch they did have 
libglvnd and may have tested that it works.

Any experts on Mesa/libglvnd here to chime in? Is the minimal Mesa version 
update patch okay if we want to libglvnd separately?

Thanks,
John