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

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

Hello,

On Mon, Oct 19, 2026 at 07:53:40AM +0200, Yann E. MORIN wrote:

> > On Sun, Oct 18, 2026 at 06:06:51PM +0200, John Ernberg wrote:
> > Thanks for this new iteration. It is really annoying that mesa3d needs
> > libglvnd, as it prevents from doing the natural thing:
> > 	libgl -> libglvnd -> real OpenGL provider -> mesa3d
> > In the end this indeed means that the only option is to do something
> > like this:
> > 	libgl -> libglvnd
> > 	      -> real OpenGL provider
> 
> Is this for build dependencies?

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.

> AFAIR, the actual GL providers do depend on libglvnd at build time,
> so we'd have:
> 
>     [GL-using package] -> libgl -> libglvnd
>                            mesa3d -/
> 
> I wonder if should further have this:
> 
>     [GL-using package] -> libgl     ->     libglvnd
>                               \-> mesa3d -/

I'm afraid I don't understand your diagrams :-/

> ... 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.

> libglvnd would allow having multiple GL (GLES, EGL, let's call all of
> that just "GL" to simplify) providers at the same time on the same
> system.
> 
> For example, some boards have two GPUs, one integrated and one discrete.
> 
> The idea of a series I sent back then [0], was when libglvnd was _not_
> enabled in the configuration, then we could have only one GL provider,
> i.e. the case currently. But when libglvnd was enabled, then multiple
> GL provider could be enabled in the same configuration.
> 
> At the time, libglvnd was relatively new, nad only mesa3d had
> support for it; the nvidia package we had (and that we still have,
> AFAICS) was too old, but newer versions (IIRC) do support being
> installed so as to be found by libglvnd.
> 
> So, the idea was to bump nvidia-driver, but that stalled for various
> reasons...
> 
> Then, we need to also check which other GL providers can be configured
> with libglnvd support.
> 
> > So shouldn't we drop libglvnd entirely?
> 
> Depends if Buildroot eventually want to support boards with two GPU, one
> integrated and one (or more) discrete. This happens.

That is understood, but libglvnd was introduced in 2020, we're in late
2026 and nobody has enabled any other GL provider to be
libglvnd-capable. So it seems like this dual GPU use case is currently
of no interest to Buildroot users?

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

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