tawasuyu

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

⎇ main recipes/libglvnd.toml TOML · 118 líneas · 7.0 KB Historia crudo

libglvnd: sólo despacho de GL — muere la colisión de libEGL. Y obs-studio llevaba meses sin construir 0cd3e6282 · Sergio ·

1# libglvnd 1.7.0 — la capa de DESPACHO de OpenGL (GL Vendor Neutral Dispatch).
2#
3# ══ POR QUÉ ENTRA: EL MURO DEL GL DE ESCRITORIO ════════════════════════════════════════════════
4# Hasta hoy NINGUNA cola publicaba `libGL.so`, `libGL.so.1` ni `gl.pc` (medido con
5# `scripts/provee.py`): mesa va `-Dglx=disabled -Dglvnd=false`, así que sólo hay `libEGL.so` y
6# `libGLESv2.so`. Consecuencia: **toda app que pida GL de escritorio compila y muere al LIGAR** —
7# mesa SÍ instala `GL/gl.h`, así que el error llega tarde y disfrazado.
8#
9# El caso que lo destapó es OBS: `deps/glad/CMakeLists.txt` linkea `PUBLIC OpenGL::GL`, que en CMake
10# ES `libGL.so`. No es un gate de configure que se pueda desactivar: es un link.
11#
12# ══ SIN GLX Y SIN X11 — LA DECISIÓN QUE HACE ESTO COHERENTE ════════════════════════════════════
13# glvnd parte el `libGL.so.1` histórico en dos piezas, y esa partición es justo lo que necesita una
14# distro Wayland-only:
15#     · `libGL.so.1`     GL **+ GLX** en una sola lib (la de siempre) ⇒ implica X11.
16#     · `libOpenGL.so.0` GL de escritorio PELADO, sin ventana ni plataforma ⇒ no implica nada.
17# Vamos por la segunda: `-Dglx=disabled -Dx11=disabled`. Un consumidor que pida `OpenGL::GL` se
18# apunta a `libOpenGL.so.0` con `-DOPENGL_gl_LIBRARY=`, y el contexto lo crea por EGL.
19#
20# Esto NO es una limitación que arrastremos: es la decisión de X11-al-tacho aplicada al stack de GL.
21# Encender glx acá metería libX11/libxcb/xorgproto —hoy sólo en `incoming-kde/`— en el CORPUS, o sea
22# en las cinco imágenes, para servir a una sola app.
23#
24# ══ QUÉ QUEDA INSTALADO ════════════════════════════════════════════════════════════════════════
25#   libGLdispatch.so.0   la tabla de despacho; el corazón, todos los demás la usan
26#   libOpenGL.so.0       GL de escritorio (lo que faltaba)
27#   libEGL.so.1          EGL, ahora como DESPACHO: el vendor real lo pone mesa (libEGL_mesa.so.0)
28#   libGLESv1_CM.so.1 / libGLESv2.so.2
29#
30# ══ 2026-09-13 · SÓLO DESPACHO DE GL: `egl/gles/headers` APAGADOS, Y ES UN ARREGLO ════════════
31# Esta receta se escribió pensando en la campaña completa —glvnd toma libEGL y mesa pasa a ser
32# vendor detrás— y la campaña NO SE HIZO: las tres mesa siguen con `-Dglvnd=false`. El resultado
33# medido, en `/mnt/cosecha/escritorios/kde-rootfs` ya hidratado, era el cuadro que el propio párrafo
34# de abajo anunciaba:
35#
36#     /usr/lib/libEGL.so.1 -> libEGL.so.1.0.0   1.440.624 B   (mesa: el driver)
37#     /usr/lib/libEGL.so.1.1.0                    323.144 B   (glvnd: despacho, HUÉRFANO)
38#
39# Dos `libEGL.so.1` distintos en la MISMA ruta, más `libGLESv2.so.2` y los headers `GL/`, `EGL/` y
40# `GLES2/` duplicados y **con bytes distintos** (`gl.h`: 79.877 vs 80.393). Quién gana depende del
41# orden de hidratación y nada lo guarda — la enfermedad de las dos glib, otra vez.
42#
43# Y no hacía falta para nada: **OBS, que es la razón de que esta receta exista, no usa glvnd en
44# runtime.** `libobs-opengl.so` sale con `NEEDED libEGL.so.1` y nada más, y sus símbolos indefinidos
45# son todos `egl*` — ni un `gl[A-Z]` sin resolver — o sea que su `glad` resuelve los punteros por
46# `eglGetProcAddress` contra la EGL de mesa. Lo único que glvnd le da es satisfacer el
47# `OpenGL::GL` de CMake **al ENLAZAR**.
48#
49# ⇒ Se apagan `egl`, `gles1`, `gles2` y `headers`. Queda lo que de verdad se usa:
50#     libGLdispatch.so.0   libOpenGL.so.0   opengl.pc
51# Cero ficheros en común con mesa ⇒ cero colisión. Radio: **1 dependiente** (obs-studio).
52#
53# ⚠ ESTO NO ES LA CAMPAÑA, ES QUITAR EL DAÑO MIENTRAS LA CAMPAÑA NO SE DECIDE. Hoy
54# `libOpenGL.so.0` enlaza y **en runtime no hay vendor** (no existe `libEGL_mesa.so.0` ni
55# `/usr/share/glvnd/egl_vendor.d/`): una app que llame de verdad por ahí encuentra una tabla vacía.
56# Cerrarlo es re-sellar las TRES mesa con `-Dglvnd=true` en un solo movimiento, y el precio está
57# medido: `yupana radio mesa` = **148 dependientes directos, 154 transitivos, 153 sellados que caen
58# a deuda, las CINCO imágenes**. Es decisión de distro, no un arreglo de paso.
59#
60# ⚠ EL CAMBIO DE DUEÑO DE libEGL NO ES MENOR. Hoy `libEGL.so.1` la instala mesa directo; con glvnd
61# la instala glvnd y mesa pasa a ser un VENDOR detrás (`-Dglvnd=true` ⇒ `libEGL_mesa.so.0` + su JSON
62# en `/usr/share/glvnd/egl_vendor.d/`). Mismo soname, otro fichero y otro dueño: si mesa se
63# reconstruye con glvnd y algo sigue hidratando el libEGL viejo, hay DOS libEGL en la ruta — el
64# cuadro de las dos glib con otra cara. Por eso mesa se reconstruye en la MISMA campaña, no después.
65#
66# Fuente por commit (ADR 0006): los `/archive/` de las forjas se generan al vuelo y su sha256 cambia
67# cuando el servidor actualiza git/gzip. `v1.7.0` es un tag LIGERO (una sola ref en `ls-remote`, sin
68# `^{}`) ⇒ este sha ES el commit.
69name    = "libglvnd"
70version = "1.7.0"
71license = "MIT"
72
73[source]
74repo   = "https://gitlab.freedesktop.org/glvnd/libglvnd.git"
75commit = "faa23f21fc677af5792825dc30cb1ccef4bf33a6"
76
77[build]
78compiler = "zig-cc"
79target   = "x86_64-linux-musl"
80# DINÁMICO y no negociable: el punto entero de glvnd es que el vendor se resuelve en RUNTIME por
81# dlopen. Una glvnd estática no despacha a nadie.
82link  = "dynamic"
83flags = []
84
85# ══ EL WRAPPER: `-Wl,--version-script` SEPARADO DE SU RUTA ═════════════════════════════════════
86# meson emite `-Wl,--version-script /src/…/export_list_tls.ver` (con ESPACIO, no con `=`). Con gcc
87# eso anda de casualidad: `-Wl,--version-script` le pasa la opción al linker y el `.ver` queda como
88# argumento suelto del DRIVER, que gcc reenvía al linker porque no sabe qué es. zig-cc es estricto y
89# lo rechaza: `error: /src/…/export_list_tls.ver: unrecognized file extension`.
90#
91# El wrapper une el par en `-Wl,--version-script=<ruta>`, que es la forma que zig sí entiende. No se
92# parchea el meson.build de upstream: el defecto no es de glvnd, es del contrato entre meson y el
93# driver, y un wrapper es reversible y no toca la fuente.
94[build.phases]
95configure = '''
96ZW="$PWD/.zwrap"; mkdir -p "$ZW"
97cat > "$ZW/cc" <<'W'
98#!/bin/sh
99a=""
100while [ $# -gt 0 ]; do
101  case "$1" in
102    -Wl,--version-script) shift; a="$a -Wl,--version-script=$1" ;;
103    *) a="$a $1" ;;
104  esac
105  shift
106done
107exec hammer-zig-cc $a
108W
109chmod +x "$ZW/cc"
110CC="$ZW/cc" PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release \
111  -Dx11=disabled -Dglx=disabled -Degl=false -Dgles1=false -Dgles2=false \
112  -Dasm=enabled -Dtls=true -Dheaders=false
113'''
114compile = "PYTHONPATH=/usr/lib/python3.12/site-packages ninja -C output"
115install = "PYTHONPATH=/usr/lib/python3.12/site-packages DESTDIR=/out meson install -C output --no-rebuild"
116
117[deps]
118build = ["meson", "samurai", "python3", "pkgconf"]