Re: [Buildroot] [RFC PATCH] package: {libgl, libglvnd, mesa3d}: Propagate libglvnd GL provider to libgl dependencies

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

On Mon, Oct 19, 2026 at 11:54:07AM +0200, Yann E. MORIN wrote:
> Thomas, All,
> 
> On 2026-10-19 09:40 +0200, Thomas Petazzoni spake thusly:
> > On Mon, Oct 19, 2026 at 07:53:40AM +0200, Yann E. MORIN wrote:
> > Yes, because right now we have:
> >         [GL-using package] -> libgl -> libglvnd
> > And separately
> >         mesa3d -> libglvnd
> > which means that [GL-using package] can be built before mesa3d, except
> > that libglvnd doesn't provide *all* what is needed to act as a GL
> > provider, for example it doesn't provide dri.pc.
> [--SNIP--]
> > > I wonder if should further have this:
> > >     [GL-using package] -> libgl     ->     libglvnd
> > >                               \-> mesa3d -/
> > I'm afraid I don't understand your diagrams :-/
> 
> * libgl depends on libglvnd
> * libgl depends on all actual GL providers (like mesa3d)
> * actual GL providers (like mesa3d) depend on libglvnd

But what are you describing here? How it _should_ work, or how it
works _today_?

Because today the part:

* libgl depends on all actual GL providers (like mesa3d)

is not there, and that's precisely the problem.

That being said: it is odd for mesa3d to provide dri.pc. This means
that if you have multiple OpenGL providers... they would all provide
their own dri.pc, overridding each other?

> > > ... even though the libgl -> mesa3d would be here just to ensure build
> > > ordering, and there would be nothing from mesa3d that the [GL-using
> > > package] would use at build time in practice. I think...
> > And that's where you're not correct, and that's the whole point of
> > John's patch in the first place. Check out his commit log for details.
> 
> Sorry, I don't have the thread history here; only digest-subscribed.

Welcome to the world of lore/lei :-)

https://lore.kernel.org/buildroot/20261018160651.349981-1-j@j-ernberg.se/

> IIRC, one of the reason to bump the nvidia-driver back at the time,
> besides the bump itself, was that the newer driver was glvnd-aware.
> But this has stalled.
> 
> Also, eventually, there are tricks to actually have multiple GL
> providers, when one uses br2-external trees, so even if GL providers
> bundled in Buildroot do not play nice with glvnd, it does not mean
> out-of-tree providers can't use it...
> 
> > Essentially, I'm trying to figure out whether we should:
> > (1) Fix this libglvnd issue by adding more complexity
> > or
> > (2) Re-simplify everything by dropping libglvnd entirely
> 
> Well, no longer my call to make anymore. I was just providing a
> recollection of what I remembered from back then.

Indeed, but I wanted to see if there was anything I was missing.

On my side, I believe I would be in favor of (2), i.e dropping
libglvnd.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot