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

["Yann E. MORIN via buildroot" <buildroot@buildroot.org>]

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

The trick will be to ensure that alibgl can depend on *all* actual GL
providers. This was easy for a single provider with the current virtual
package mechanism, esp. for providers in br2-external trees, but that
won't be usable when we allow for multiple providers...

This is where the complexity might creep in...

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

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

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.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot