[Buildroot] [PATCH 2/2 v4] package/mesa3d: make it aware of libglvnd and support it when present

Thomas Petazzoni thomas.petazzoni at bootlin.com
Mon Jul 27 15:38:44 UTC 2020

On Mon, 27 Jul 2020 10:47:02 +0200
"Yann E. MORIN" <yann.morin.1998 at free.fr> wrote:

> From: Jakub Skrzypnik <jskrzypnik at novomatic-tech.com>
> When libglvnd is enabled, mesa3d must be told so, so as it installs its
> libraries with the vendor suffix (e.g. libEGL_mesa.so instead of
> libEGL.so).
> Additionally, the provider (in Buildroot parlance) is libglvnd, not mesa3d.
> Signed-off-by: Jakub Skrzypnik <jskrzypnik at novomatic-tech.com>
> [yann.morin.1998 at free.fr:
>   - don't override the _PROVIDES variable, only assign when needed
> ]
> Signed-off-by: Yann E. MORIN <yann.morin.1998 at free.fr>
> ---
>  package/mesa3d/Config.in | 15 +++++++++------
>  package/mesa3d/mesa3d.mk | 15 +++++++++++----
>  2 files changed, 20 insertions(+), 10 deletions(-)
> diff --git a/package/mesa3d/Config.in b/package/mesa3d/Config.in
> index 11d04b7a3f..5417aeda1a 100644
> --- a/package/mesa3d/Config.in
> +++ b/package/mesa3d/Config.in
> @@ -422,7 +422,8 @@ comment "gbm support needs a dri driver or a gallium driver w/ EGL support."
>  	bool "OpenGL GLX"
>  	depends on BR2_PACKAGE_XORG7

I don't immediately see a good solution for this, but I find that
solution to be quite annoying :-/

Indeed, I understand that once libglvnd is enabled, the GL-provider is
libglvnd, which in the background is using mesa3d. The dance to handle
libglvnd in mesa3d is already not nice, and we would have to have the
same dance in other GL providers that support libglvnd.

OK, here is some vague idea for a possible solution:

 - We introduce an intermediate "layer" between libgl and GL providers.

 - GL provides no longer provide directly libgl, but instead some kind
   of libgl-low, libgl-real (or some better name)

 - libgl is then provided either by libglvnd on top of
   libgl-low/libgl-real, *or* on top of some simple libgl-proxy package
   that does nothing but make libgl depend on libgl-low

I *think* this would perhaps avoid that complexity in mesa3d...
obviously for additional complexity in terms of how the virtual
packages in GL world all work together.

Would this make sense ? Is it over-engineered ?

Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering

More information about the buildroot mailing list