Files
Sergio a828e74c40 la cadena GTK3 se enlazaba estática dentro de dos .so: cuatro variantes -shared y xkeyboard-config al corpus
Con `atk` arreglado, atuq llegó más lejos y murió igual, ahora con Pango:

    GLib-GObject-CRITICAL: cannot register existing type 'PangoFontMap'
    … decenas de líneas … tipo '<invalid>'

MISMO CUADRO, CULPABLE DISTINTO Y MÁS GRANDE. `gtk3` produce DOS objetos compartidos —libgtk-3.so y
libgdk-3.so— y libxul declara NEEDED las dos, así que se cargan siempre juntas. Con las variantes
ESTÁTICAS de sus deps, cada una se llevaba adentro su propia copia. Medido con el mismo instrumento
que cazó a atk, `nm -D --defined-only`, preguntando quién DEFINE cada símbolo:

    pango_font_map_get_type → libgdk-3.so, libgtk-3.so, libgailutil-3.so
    cairo_create            → libgdk-3.so, libgtk-3.so
    gdk_pixbuf_get_type     → libgdk-3.so, libgtk-3.so
    hb_buffer_create        → libgdk-3.so, libgtk-3.so, libgailutil-3.so

Y se comprobó el otro lado: libxul NO embebe ninguna —enlaza libgtk-3/libgdk-3 como debe—, así que
la duplicación es toda interna del par GTK3.

Cuatro variantes nuevas: harfbuzz-shared, cairo-shared, gdk-pixbuf-shared, pango-shared. Sólo cambia
el modo de librería; se conservan todos los switches del canónico para no arrastrar deps nuevas.

DOS DEUDAS ANOTADAS, NO OLVIDADAS: `fribidi` y `pixman` siguen estáticos —no existe variante— pero
quedan embebidos en UNA sola .so cada uno, así que no hay copia que colisione; y `libepoxy` sí queda
en las dos, y se deja porque no registra tipos de GObject ni mantiene estado global. Si algún día
otra .so del mismo proceso los embebe, vuelve el cuadro.

`firefox` swapea las mismas cuatro: declarar las ESTÁTICAS junto a un gtk3 que trae las compartidas
son dos artefactos peleando por el mismo `pango.pc`, que es la otra forma conocida de este fallo.

Y `xkeyboard-config` SUBE AL CORPUS. Existía idéntica en las cuatro colas de escritorio (un solo md5
entre las cuatro, verificado antes de mover) y atuq, que vive en el corpus, no podía alcanzar
ninguna: sibling-first y después el catálogo padre, nunca una cola hermana. Sin sus datos el
navegador ni pinta («xkbcommon: failed to add default include path /usr/share/X11/xkb»). Mismo hash
en el corpus que en las colas ⇒ cero rebuilds, y las copias de las colas se quedan donde están.
2026-09-05 12:02:24 +00:00

89 lines
5.8 KiB
TOML

# GTK 3.24.43 — el toolkit de Gecko. LA PIEZA CLAVE DE LA PLATAFORMA GECKO.
#
# ══ POR QUÉ EXISTE ESTA RECETA ═════════════════════════════════════════════════════════════════
# Firefox no tiene alternativa: en Linux su único toolkit es GTK3 (`widget/gtk`). Y **Waterfox y Zen
# son forks de Gecko**, así que los tres consumen exactamente esta misma pieza. Una sola receta
# sostiene a los tres navegadores — de ahí que valga la pena ponerla en el CORPUS y no en una cola.
#
# Al medir el cierre antes de escribirla, TODO lo que pide ya estaba en el corpus salvo `atk`, que se
# escribió primero. No es una torre nueva: es una pieza que faltaba sobre cimientos ya puestos.
#
# ══ WAYLAND-ONLY: `-Dx11_backend=false` ════════════════════════════════════════════════════════
# La distro es Wayland-only por decisión firme, y GTK3 permite compilar SIN el backend X11 — a
# diferencia de OBS, que exigía `find_package(X11)` incondicional. Apagarlo saca de un plumazo
# libX11/libXext/libXi/libXrandr/libXcursor/libXdamage/libXcomposite/libXfixes/libXinerama del
# cierre: **la cadena X11 vive sólo en `incoming-kde`, y meterla en el CORPUS la pondría en las cinco
# imágenes**. Este flag es lo que mantiene la plataforma Gecko coherente con la postura de la distro.
#
# ⚠ Consecuencia que hay que tener escrita: un Firefox construido contra este GTK3 **no puede correr
# bajo X11 ni bajo Xwayland como cliente X**. Bajo Wayland nativo sí. No es una limitación
# accidental, es la postura de la distro aplicada al navegador.
#
# ══ LO DEMÁS QUE SE APAGA ══════════════════════════════════════════════════════════════════════
# introspection sólo la usan los bindings dinámicos (gjs/PyGObject); Gecko consume GTK en C.
# Evita arrastrar gobject-introspection y repetir la torre de GNOME sin motivo.
# demos/examples/ son programas de muestra: no entran al artefacto y alargan el build.
# tests
# cloudproviders, integraciones opcionales (Dropbox y compañía, impresión por CUPS, colorimetría):
# print_backends, ninguna hace falta para que un navegador dibuje, y cada una es una lib más.
# colord
# gtk_doc gtk-doc no está en el corpus.
name = "gtk3"
version = "3.24.43"
license = "LGPL-2.1-or-later"
[source]
tarball = "https://download.gnome.org/sources/gtk+/3.24/gtk+-3.24.43.tar.xz"
sha256 = "7e04f0648515034b806b74ae5d774d87cffb1a2a96c468cb5be476d51bf2f3c7"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
# DINÁMICO y no negociable: GTK carga módulos (temas, IM, print) por dlopen, y Gecko linkea
# `libgtk-3.so.0` por SONAME. Un GTK estático no abre una ventana.
link = "dynamic"
flags = []
[build.phases]
configure = '''
PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release \
-Ddefault_library=shared \
-Dwayland_backend=true -Dx11_backend=false -Dbroadway_backend=false \
-Dintrospection=false -Ddemos=false -Dexamples=false -Dtests=false \
-Dgtk_doc=false -Dman=false \
-Dcloudproviders=false -Dprint_backends=file -Dcolord=no
'''
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"
# `.pc Requires` → `[deps].build`, el patrón del corpus: gtk+-3.0.pc pide gdk-pixbuf, pango, cairo,
# atk, glib y epoxy; cada uno arrastra los suyos (harfbuzz→glib, pango→fribidi+harfbuzz,
# gdk-pixbuf→libpng/libjpeg/libtiff, cairo→pixman/freetype/fontconfig).
[deps]
# ⚠ VARIANTES `-shared`, Y **EN LUGAR DE** LAS ESTÁTICAS, NUNCA JUNTO A ELLAS. `libgtk-3.so` es un
# objeto compartido: un `.a` sin PIC adentro da `relocation R_X86_64_32 cannot be used against symbol
# 'png_default_write_data'`, el mismo cuadro de gdk-pixbuf. Las variantes existen en el corpus desde
# la campaña de GTK4 — buscar antes de escribir.
# Se SUSTITUYE porque las dos variantes instalan **los mismos `.pc` y las mismas cabeceras**
# (verificado listando los dos artefactos): declarar ambas serían dos artefactos peleando por
# `lib/pkgconfig/glib-2.0.pc`. Una u otra, jamás las dos.
build = [
"meson", "samurai", "python3", "pkgconf",
# ── LAS VARIANTES `-shared`, PORQUE gtk3 PRODUCE DOS `.so` (2026-09-05) ──────────────────────
# `libgtk-3.so` y `libgdk-3.so` se cargan SIEMPRE juntas (libxul declara NEEDED las dos). Con las
# variantes estáticas, cada una se llevaba su propia copia de pango, cairo, gdk-pixbuf y harfbuzz
# adentro ⇒ dos sistemas de tipos de Pango en un proceso, y el navegador moría antes de pintar:
# GLib-GObject-CRITICAL: cannot register existing type 'PangoFontMap'
# Medido con `nm -D --defined-only` sobre cada `.so`, preguntando quién DEFINE
# `pango_font_map_get_type` — salieron libgtk-3 y libgdk-3, y ninguna debía.
# ⚠ `libepoxy` sigue estático y también queda embebido en las dos: se deja porque NO registra
# tipos de GObject ni mantiene estado global compartido, así que la duplicación no colisiona. Es
# deuda anotada, medida, no un olvido.
"atk", "gdk-pixbuf-shared", "pango-shared", "cairo-shared", "libepoxy",
"glib-shared", "pcre2-shared", "libffi-shared", "zlib-shared",
"harfbuzz-shared", "fribidi", "freetype-shared", "fontconfig-shared", "pixman",
"libpng-shared", "libjpeg-turbo-shared", "libtiff-shared",
"wayland", "wayland-protocols", "libxkbcommon",
"libxml2-shared", "mesa", "libdrm",
]