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

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

[John Ernberg]

A package depending on libgl doesn't obtain all the provided features
of the package that libglvnd uses as a GL provider.

When building xorg-server with this configuration appended to the
x86_64_efi_defconfig:

    +BR2_PER_PACKAGE_DIRECTORIES=y
    +BR2_PACKAGE_LIBGLVND=y
    +BR2_PACKAGE_MESA3D=y
    +BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_NOUVEAU=y
    +BR2_PACKAGE_MESA3D_OPENGL_GLX=y
    +BR2_PACKAGE_XORG7=y
    +BR2_PACKAGE_XSERVER_XORG_SERVER=y

The build will fail with the following error:

    configure: error: Package requirements (fixesproto >= 6.0
    damageproto >= 1.1 xcmiscproto >= 1.2.0 xtrans >= 1.3.5 bigreqsproto
    >= 1.1.0 xproto >= 7.0.31 randrproto >= 1.6.0 renderproto >= 0.11
    xextproto >= 7.2.99.901 inputproto >= 2.3.99.1 kbproto >= 1.0.3
    fontsproto >= 2.1.3 pixman-1 >= 0.27.2 videoproto recordproto >=
    1.13.99.1 resourceproto >= 1.2.0 xf86driproto >= 2.1.0 glproto >=
    1.4.17 dri >= 7.8.0 dri3proto presentproto >= 1.2 xineramaproto
    xkbfile  pixman-1 >= 0.27.2 xfont2 >= 2.0.0 xau xshmfence >= 1.1
    xdmcp) were not met:

    Package 'dri' not found

    Consider adjusting the PKG_CONFIG_PATH environment variable if you
    installed software in a non-standard prefix.

xwayland will fail with a similar error, not finding dri.

This is because dri.pc is in this configuration is provided by mesa3d,
but libgl is provided by libglvnd, which does not depend on mesa3d
(because mesa3d depends on libglvnd to build the interface used by
libglvnd).

If libglvnd is extended to cover the nvidia-driver, dri.pc would be
provided by mesa3d-headers.

It seems that only libgl usually needs this extra bit, so EGL and GLES
are left untouched.

Cc: Adam Ford <aford173@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Bernd Kuhls <bernd@kuhls.net>
Cc: Joseph Kogut <joseph.kogut@gmail.com>
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: John Ernberg <j@j-ernberg.se>

---

Previous approach adding mesa3d and mesa3d-headers conditionally to
xorg-server and xwayland was deemed incorrect [1].

RFC: Does this make sense, or should dri.pc providers be virtual
instead?

[1]: https://lore.kernel.org/buildroot/20260927204842.1113860-1-j@j-ernberg.se/
---
 package/libglvnd/Config.in    | 6 ++++++
 package/mesa3d/Config.in      | 3 +++
 package/opengl/libgl/libgl.mk | 9 +++++++++
 3 files changed, 18 insertions(+)

diff --git a/package/libglvnd/Config.in b/package/libglvnd/Config.in
index f471e289bd..b0d8a4efcb 100644
--- a/package/libglvnd/Config.in
+++ b/package/libglvnd/Config.in
@@ -27,6 +27,12 @@ config BR2_PACKAGE_LIBGLVND_DISPATCH_GL
 	select BR2_PACKAGE_XORGPROTO
 	select BR2_PACKAGE_HAS_LIBGL
 
+# So far only GL dependant packages are known to need other parts of
+# the dispatch GL providers components (e.g. xorg-xserver)
+config BR2_PACKAGE_LIBGLVND_DISPATCH_GL_PROVIDER
+	string
+	depends on BR2_PACKAGE_LIBGLVND_DISPATCH_GL
+
 config BR2_PACKAGE_LIBGLVND_DISPATCH_EGL
 	bool
 	select BR2_PACKAGE_HAS_LIBEGL
diff --git a/package/mesa3d/Config.in b/package/mesa3d/Config.in
index e184039150..fc99345e32 100644
--- a/package/mesa3d/Config.in
+++ b/package/mesa3d/Config.in
@@ -488,6 +488,9 @@ config BR2_PACKAGE_MESA3D_OPENGL_GLX
 	help
 	  Enable GLX graphic acceleration (OpenGL + X11).
 
+config BR2_PACKAGE_LIBGLVND_DISPATCH_GL_PROVIDER
+	default "mesa3d" if BR2_PACKAGE_LIBGLVND && BR2_PACKAGE_LIBGLVND_DISPATCH_GL
+
 comment "OpenGL GLX support needs X11"
 	depends on !BR2_PACKAGE_XORG7
 
diff --git a/package/opengl/libgl/libgl.mk b/package/opengl/libgl/libgl.mk
index 7abc13d637..c747297ec0 100644
--- a/package/opengl/libgl/libgl.mk
+++ b/package/opengl/libgl/libgl.mk
@@ -4,4 +4,13 @@
 #
 ################################################################################
 
+# The dependency is for libgl consumers, not for the libglvnd package
+# as that creates a circular dependency since some providers need
+# libglvnd to build their compatible interfaces (e.g. mesa3d).
+ifeq ($(BR2_PACKAGE_LIBGLVND),y)
+ifneq ($(call qstrip,$(BR2_PACKAGE_LIBGLVND_DISPATCH_GL_PROVIDER)),)
+LIBGL_DEPENDENCIES += $(call qstrip,$(BR2_PACKAGE_LIBGLVND_DISPATCH_GL_PROVIDER))
+endif
+endif
+
 $(eval $(virtual-package))
-- 
2.54.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Thomas Petazzoni via buildroot]

Hello John,

[+Yann since he added libglvnd initially.]

On Sun, Oct 18, 2026 at 06:06:51PM +0200, John Ernberg wrote:

> xwayland will fail with a similar error, not finding dri.
> 
> This is because dri.pc is in this configuration is provided by mesa3d,
> but libgl is provided by libglvnd, which does not depend on mesa3d
> (because mesa3d depends on libglvnd to build the interface used by
> libglvnd).
> 
> If libglvnd is extended to cover the nvidia-driver, dri.pc would be
> provided by mesa3d-headers.
> 
> It seems that only libgl usually needs this extra bit, so EGL and GLES
> are left untouched.

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

Now, the questions that come up are:

- Why do you need libglvnd in the first place? Why don't you just
  enable mesa3d?

- Why do we have libglvnd at all? It has been added in 2020, but so
  far only mesa3d has been made "suitable" to be used behind libglvnd,
  and since we have only one OpenGL provider able to be used behind
  libglvnd, the abstraction that libglvnd provides seems quite
  useless, no?

So shouldn't we drop libglvnd entirely?

Otherwise, I guess we would indeed need some additional virtual
package like "real-libgl". mesa3d would provide libgl when !libglvnd,
and would provide real-libgl when libglvnd. And libgl would add a
dependency on real-libgl when libglvnd is enabled. This is a bit like
your proposal John, just generalized a bit so that potentially other
OpenGL providers than mesa3d can be used behind libglvnd. But before
going this route, let's figure out if we want to keep libglvnd at all.

Thanks!

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

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

[John Ernberg]

Hi Thomas,

On Sun, Oct 18, 2026 at 10:41 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello John,
>
> [+Yann since he added libglvnd initially.]
>
> On Sun, Oct 18, 2026 at 06:06:51PM +0200, John Ernberg wrote:
>
> > xwayland will fail with a similar error, not finding dri.
> >
> > This is because dri.pc is in this configuration is provided by mesa3d,
> > but libgl is provided by libglvnd, which does not depend on mesa3d
> > (because mesa3d depends on libglvnd to build the interface used by
> > libglvnd).
> >
> > If libglvnd is extended to cover the nvidia-driver, dri.pc would be
> > provided by mesa3d-headers.
> >
> > It seems that only libgl usually needs this extra bit, so EGL and GLES
> > are left untouched.
>
> 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
>
> Now, the questions that come up are:
>
> - Why do you need libglvnd in the first place? Why don't you just
>   enable mesa3d?

I'm just running mass builds working on finding conflicting packages,
to hopefully in the end solve the per-package rebuilds as initially
discussed with Arnout here:
https://lore.kernel.org/buildroot/20241227160622.1654822-1-john.ernberg@actia.se/T/#u

I run into quite a bunch of build failures in the process.

Personally I have no interest in libglvnd other than being able to
build "allyesconfig"-like configurations to find conflicts.

I'm also open to ripping libglvnd out if there is no use for it.

Best regards // John Ernberg
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Yann E. MORIN via buildroot]

Thomas, All,

On 2026-10-18 22:41 +0200, Thomas Petazzoni spake thusly:
> [+Yann since he added libglvnd initially.]

Actually, it was Jakub would introduced it in 2020, I "only" reworked
the package, and it was applied in 2022 with 0378e2e5d9ce
(package/libglvnd: new package).

But that was a long time ago, and my recollecion of the details is
partial... Let's see below...

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

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

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

> Now, the questions that come up are:
> - Why do you need libglvnd in the first place? Why don't you just
>   enable mesa3d?
> - Why do we have libglvnd at all? It has been added in 2020, but so
>   far only mesa3d has been made "suitable" to be used behind libglvnd,
>   and since we have only one OpenGL provider able to be used behind
>   libglvnd, the abstraction that libglvnd provides seems quite
>   useless, no?

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.

[0] https://lore.kernel.org/buildroot/cover.1595839612.git.yann.morin.1998@free.fr/

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

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

[Thomas Petazzoni via buildroot]

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

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

[Thomas Petazzoni via buildroot]

On Sun, Oct 18, 2026 at 10:57:15PM +0200, John Ernberg wrote:

> I'm just running mass builds working on finding conflicting packages,
> to hopefully in the end solve the per-package rebuilds as initially
> discussed with Arnout here:
> https://lore.kernel.org/buildroot/20241227160622.1654822-1-john.ernberg@actia.se/T/#u
> 
> I run into quite a bunch of build failures in the process.
> 
> Personally I have no interest in libglvnd other than being able to
> build "allyesconfig"-like configurations to find conflicts.
> 
> I'm also open to ripping libglvnd out if there is no use for it.

OK, thanks for your feedback. Let's see the outcome of the
conversation started with Yann to decide what we do with 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

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

[Yann E. MORIN via buildroot]

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

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

[Thomas Petazzoni via buildroot]

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