GNU bug report logs -
#74522
[PATCH 00/73] Moving Guix to libglvnd
Previous Next
Full log
View this message in rfc822 format
On Wed, 02 Apr 2025 14:45:21 +0800,
Z572 wrote:
>
> [1 <text/plain (7bit)>]
> Hilton Chain <hako <at> ultrarare.space> writes:
>
> > On Wed, 02 Apr 2025 13:18:03 +0800,
> > Maxim Cournoyer wrote:
> >>
> >> Hello,
> >>
> >> John Kehayias <john.kehayias <at> protonmail.com> writes:
> >>
> >> [...]
> >>
> >> > Using libglvnd has come up a few times in the past, and unfortunately I
> >> > don't have a way to test what it may be most helpful for (on foreign
> >> > distros? or multi-gpu setups?).
> >> >
> >> > I had to refresh myself on this long patch series, so my apologies if I
> >> > missed something, but this looks to be a lot of unnecessary work, no?
> >> > The "libgl" package and all the dependent input changes is essentially
> >> > the same as propagating libglvnd from mesa? (I'm not sure about the
> >> > build changes in there though, didn't look, but I have built mesa with
> >> > libglvnd before just fine.)
> >> >
> >> > In any event, I think the approach discussed way back in
> >> > <https://issues.guix.gnu.org/49339#8> makes the most sense to me and
> >> > seems like not as much work:
> >> >
> >> > 1. Add libglvnd to Mesa, that enables libglvnd support automatically
> >> >
> >> > 2. Propagate libglvnd from Mesa, assuming that fixes many packages;
> >> > seems like it would be okay as libglvnd isn't something a user would
> >> > install on its own
> >> >
> >> > 3. Fix any packages searching their input's mesa for libraries to search
> >> > libglvnd, as needed. From the old discussion this seemed to be a
> >> > manageable (small) number of packages with a straightforward fix.
> >>
> >> That would be a good way to minimize the code change, but in my opinion
> >> is a bit less clean w.r.t. what libglvnd aims to be: an
> >> abstraction/indirection of the libGL.so implementation. So if we want
> >> to truly move to the modern world of where packages get purely linked to
> >> libglvnd, which in turns dispatches to either mesa or some other
> >> implementation (configurable at the system level, IIRC), it seems it'd
> >> be more Guixy to have only libglvnd exposed to builds instead of both
> >> libglvnd and mesa.
> >>
> >> So I think the original patches look fine, but given the mechanical
> >> changes that should (mostly?) be doable with a sed substitution, I'd
> >> suggestion doing that in single commit and mentioning which command was
> >> used in place of the GNU ChangeLog (I had suggested that earlier in
> >> thread in my reply to patch 20/73).
> >>
> >> Would 'The Man' or someone like to tackle that?
> >>
> >> You could test this sed command a new branch, and after the automated
> >> conversion, diffing the new branch against the old one should give no
> >> difference.
> >
> > Is there a real use case for libglvnd that doesn't involve a proprietary
> > graphics driver? If the answer is no, I don't it worth the new complexity.
>
> I think one use case is to be able to use different versions of mesa,
> for example archlinux has the mesa-amber[1] package to support classic
> OpenGL (non-Gallium3D) drivers
>
> and test using newer versions of mesa.
>
> [1] https://archlinux.org/packages/extra/x86_64/mesa-amber/
Sounds valid.
Just thought about this, some changes used for the nvda package may be required
for a functional GLVND support (there's also one for multilib!):
https://gitlab.com/nonguix/nonguix/-/blob/a96e2451bda5aaf9b48339edee392c6a3017d730/nongnu/packages/nvidia.scm#L694
This bug report was last modified 48 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.