guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Kehayias
Subject: [bug#49339] [PATCH core-updates] gnu: mesa: Update to 21.1.4.
Date: Fri, 09 Jul 2021 02:41:56 +0000

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

On Thursday, July 8th, 2021 at 4:55 PM, Maxime Devos wrote:

> John Kehayias via Guix-patches via schreef op do 08-07-2021 om 01:35 [+0000]:
>
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> >
> > On Monday, July 5th, 2021 at 11:35 AM:
> >
> > > libepoxy doesn't build (patch paths?). On #guix there was discussion of 
> > > fixing these problems, could an updated patch be sent here for testing?
> >
> > This was easy to solve: I switched where libepoxy was looking for EGL and 
> > GL libraries to use libglvnd rather than mesa, as well as adding libglvnd 
> > as an input. Also added libglvnd as an input into xorg-server.
> >
> > Looking at other packages that depend on e.g. libepoxy/mesa/etc. seems like 
> > many will need libglvnd as an input now? Is that what we want to move to (I 
> > take it is optional, but perhaps a move in the right direction)?
>
> If with this update of mesa, (almost) every package using mesa also needs 
> libglvnd,
>
> then why not add 'libglvnd' to the propagated-inputs mesa, for about the same 
> reasons
>
> that 'atk' has 'glib' in 'propagated-inputs'?
>
> Not sure if the comparison applies though.
>
> Greetings,
>
> Maxime

Hi Maxime,

That sounds like a good idea, but I think there may be some kinks to work out. 
Adding libglvnd to propagated-inputs of Mesa does lead to the successful 
building of dependents (tested on libepoxy and virtualgl, for example). 
However, libepoxy fails on a test because it doesn't find libGL. That is no 
longer in Mesa's lib but from libglvnd if I'm understanding correctly. May just 
be a problem with the test since building works (which checks for GL).

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?

John





reply via email to

[Prev in Thread] Current Thread [Next in Thread]