libglvnd 1.7.0: el GL de escritorio que a la distro le faltaba

Hasta hoy NINGUNA cola publicaba libGL.so, libGL.so.1 ni gl.pc (medido con
provee.py): mesa va -Dglx=disabled -Dglvnd=false, así que sólo había libEGL y
libGLESv2. Toda app de GL fijo compilaba —mesa SÍ instala GL/gl.h— y moría al
LIGAR. Lo destapó OBS: deps/glad linkea PUBLIC OpenGL::GL, que ES libGL.so, y eso
es un link, no un gate de configure que se pueda apagar.

SIN GLX Y SIN X11, que es lo que hace esto coherente con la distro: glvnd parte el
libGL.so.1 histórico en libGL.so.1 (GL+GLX ⇒ implica X11) y libOpenGL.so.0 (GL
pelado ⇒ no implica nada). Vamos por la segunda. Encender glx metería
libX11/libxcb/xorgproto —hoy sólo en incoming-kde— en el CORPUS, o sea en las
cinco imágenes, para servir a una sola app.

Entrega verificada en el artefacto: libOpenGL.so.0, libGLdispatch.so.0,
libEGL.so.1, libGLESv{1_CM,2}, y opengl.pc. Cero GLX.

El wrapper: meson emite `-Wl,--version-script <ruta>` con ESPACIO. Con gcc anda de
casualidad (reenvía al linker el argumento suelto que no entiende); zig-cc lo
rechaza con «unrecognized file extension». El wrapper une el par con `=`. No se
parchea upstream: el defecto es del contrato meson↔driver, no de glvnd.

⚠ Instala libEGL.so.1, que HOY la pone mesa. Mismo soname, otro dueño ⇒ mesa se
reconstruye con -Dglvnd=true en esta misma campaña, no después.

recipes/libglvnd.toml

@@ -0,0 +1,88 @@
+# libglvnd 1.7.0 — la capa de DESPACHO de OpenGL (GL Vendor Neutral Dispatch).
+#
+# ══ POR QUÉ ENTRA: EL MURO DEL GL DE ESCRITORIO ════════════════════════════════════════════════
+# Hasta hoy NINGUNA cola publicaba `libGL.so`, `libGL.so.1` ni `gl.pc` (medido con
+# `scripts/provee.py`): mesa va `-Dglx=disabled -Dglvnd=false`, así que sólo hay `libEGL.so` y
+# `libGLESv2.so`. Consecuencia: **toda app que pida GL de escritorio compila y muere al LIGAR** —
+# mesa SÍ instala `GL/gl.h`, así que el error llega tarde y disfrazado.
+#
+# El caso que lo destapó es OBS: `deps/glad/CMakeLists.txt` linkea `PUBLIC OpenGL::GL`, que en CMake
+# ES `libGL.so`. No es un gate de configure que se pueda desactivar: es un link.
+#
+# ══ SIN GLX Y SIN X11 — LA DECISIÓN QUE HACE ESTO COHERENTE ════════════════════════════════════
+# glvnd parte el `libGL.so.1` histórico en dos piezas, y esa partición es justo lo que necesita una
+# distro Wayland-only:
+#     · `libGL.so.1`     GL **+ GLX** en una sola lib (la de siempre) ⇒ implica X11.
+#     · `libOpenGL.so.0` GL de escritorio PELADO, sin ventana ni plataforma ⇒ no implica nada.
+# Vamos por la segunda: `-Dglx=disabled -Dx11=disabled`. Un consumidor que pida `OpenGL::GL` se
+# apunta a `libOpenGL.so.0` con `-DOPENGL_gl_LIBRARY=`, y el contexto lo crea por EGL.
+#
+# Esto NO es una limitación que arrastremos: es la decisión de X11-al-tacho aplicada al stack de GL.
+# Encender glx acá metería libX11/libxcb/xorgproto —hoy sólo en `incoming-kde/`— en el CORPUS, o sea
+# en las cinco imágenes, para servir a una sola app.
+#
+# ══ QUÉ QUEDA INSTALADO ════════════════════════════════════════════════════════════════════════
+#   libGLdispatch.so.0   la tabla de despacho; el corazón, todos los demás la usan
+#   libOpenGL.so.0       GL de escritorio (lo que faltaba)
+#   libEGL.so.1          EGL, ahora como DESPACHO: el vendor real lo pone mesa (libEGL_mesa.so.0)
+#   libGLESv1_CM.so.1 / libGLESv2.so.2
+#
+# ⚠ EL CAMBIO DE DUEÑO DE libEGL NO ES MENOR. Hoy `libEGL.so.1` la instala mesa directo; con glvnd
+# la instala glvnd y mesa pasa a ser un VENDOR detrás (`-Dglvnd=true` ⇒ `libEGL_mesa.so.0` + su JSON
+# en `/usr/share/glvnd/egl_vendor.d/`). Mismo soname, otro fichero y otro dueño: si mesa se
+# reconstruye con glvnd y algo sigue hidratando el libEGL viejo, hay DOS libEGL en la ruta — el
+# cuadro de las dos glib con otra cara. Por eso mesa se reconstruye en la MISMA campaña, no después.
+#
+# Fuente por commit (ADR 0006): los `/archive/` de las forjas se generan al vuelo y su sha256 cambia
+# cuando el servidor actualiza git/gzip. `v1.7.0` es un tag LIGERO (una sola ref en `ls-remote`, sin
+# `^{}`) ⇒ este sha ES el commit.
+name    = "libglvnd"
+version = "1.7.0"
+license = "MIT"
+
+[source]
+repo   = "https://gitlab.freedesktop.org/glvnd/libglvnd.git"
+commit = "faa23f21fc677af5792825dc30cb1ccef4bf33a6"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+# DINÁMICO y no negociable: el punto entero de glvnd es que el vendor se resuelve en RUNTIME por
+# dlopen. Una glvnd estática no despacha a nadie.
+link  = "dynamic"
+flags = []
+
+# ══ EL WRAPPER: `-Wl,--version-script` SEPARADO DE SU RUTA ═════════════════════════════════════
+# meson emite `-Wl,--version-script /src/…/export_list_tls.ver` (con ESPACIO, no con `=`). Con gcc
+# eso anda de casualidad: `-Wl,--version-script` le pasa la opción al linker y el `.ver` queda como
+# argumento suelto del DRIVER, que gcc reenvía al linker porque no sabe qué es. zig-cc es estricto y
+# lo rechaza: `error: /src/…/export_list_tls.ver: unrecognized file extension`.
+#
+# El wrapper une el par en `-Wl,--version-script=<ruta>`, que es la forma que zig sí entiende. No se
+# parchea el meson.build de upstream: el defecto no es de glvnd, es del contrato entre meson y el
+# driver, y un wrapper es reversible y no toca la fuente.
+[build.phases]
+configure = '''
+ZW="$PWD/.zwrap"; mkdir -p "$ZW"
+cat > "$ZW/cc" <<'W'
+#!/bin/sh
+a=""
+while [ $# -gt 0 ]; do
+  case "$1" in
+    -Wl,--version-script) shift; a="$a -Wl,--version-script=$1" ;;
+    *) a="$a $1" ;;
+  esac
+  shift
+done
+exec hammer-zig-cc $a
+W
+chmod +x "$ZW/cc"
+CC="$ZW/cc" PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release \
+  -Dx11=disabled -Dglx=disabled -Degl=true -Dgles1=true -Dgles2=true \
+  -Dasm=enabled -Dtls=true -Dheaders=true
+'''
+compile = "PYTHONPATH=/usr/lib/python3.12/site-packages ninja -C output"
+install = "PYTHONPATH=/usr/lib/python3.12/site-packages DESTDIR=/out meson install -C output --no-rebuild"
+
+[deps]
+build = ["meson", "samurai", "python3", "pkgconf"]