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.
This commit is contained in:
Sergio
2026-09-05 12:02:24 +00:00
parent 0bda91a374
commit a828e74c40
8 changed files with 213 additions and 5 deletions
+40
View File
@@ -0,0 +1,40 @@
# cairo-shared 1.18.4 — variante DINÁMICA. **Existe por un fallo medido, no por simetría.**
#
# El canónico (`recipes/cairo.toml`) es `-Ddefault_library=static`, así que quien lo enlaza se lo
# traga entero. Y `gtk3` produce DOS objetos compartidos —`libgtk-3.so` y `libgdk-3.so`—, de modo
# que cada uno se llevaba su propia copia. Los dos se cargan siempre juntos (libxul los declara
# NEEDED a los dos) ⇒ dos copias en un proceso, y el navegador moría antes de pintar:
#
# GLib-GObject-CRITICAL: cannot register existing type 'PangoFontMap'
# … decenas de líneas … tipo '<invalid>'
#
# Se midió con `nm -D --defined-only` sobre cada `.so` del rootfs, preguntando quién DEFINE
# `pango_font_map_get_type` / `cairo_create` / `gdk_pixbuf_get_type` / `hb_buffer_create`.
# Respuesta: `libgtk-3.so` Y `libgdk-3.so`, las dos. Debía ser una sola librería, y ninguna de ellas.
#
# Es la misma regla que ya arrastraba el corpus desde GTK4 y que la cadena GTK3 se había saltado:
# **las deps de una `.so` van a las variantes `-shared`, en lugar de las estáticas y jamás junto a
# ellas** (las dos instalan los mismos `.pc` y cabeceras).
#
# ⚠ `pixman` sigue estático: no hay variante `-shared`. Queda embebido sólo acá ⇒ una copia. Deuda
# anotada; el día que otra `.so` del mismo proceso también lo lleve, reaparece el choque.
#
# Sólo cambia el modo de librería: se conservan TODOS los switches del canónico para no arrastrar
# deps nuevas ni cambiar qué se construye.
name = "cairo-shared"
version = "1.18.4"
license = "LGPL-2.1-only OR MPL-1.1"
[source]
tarball = "https://gitlab.freedesktop.org/cairo/cairo/-/archive/1.18.4/cairo-1.18.4.tar.bz2"
sha256 = "6d9281e786fd289d382324d4588d59973a36911e1865b40e64f9ec39936ceba8"
patches = ["cairo-ctime-r.patch"]
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "dynamic"
[build.phases]
configure = "PKG_CONFIG_PATH=/usr/lib/pkgconfig PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release --wrap-mode=nodownload -Ddefault_library=shared -Dc_args=-Wno-error=date-time -Dtests=disabled -Dxlib=disabled -Dxcb=disabled -Dquartz=disabled -Dtee=disabled -Dsymbol-lookup=disabled -Dspectre=disabled -Dgtk_doc=false -Dpng=enabled -Dfreetype=enabled -Dfontconfig=enabled -Dglib=enabled"
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", "pixman", "freetype-shared", "fontconfig-shared", "libpng-shared", "zlib-shared", "glib-shared", "expat-shared", "libffi-shared", "pcre2-shared"]
+6 -2
View File
@@ -283,9 +283,13 @@ build = [
# `/usr/bin`—, así que la respuesta no es apuntar el AR a mano: es NO traer el 18.
# Es además lo que hace Alpine: clang22 + clang22-libclang, sin un segundo LLVM en la mesa.
"nodejs", "cbindgen",
"gtk3", "atk", "gdk-pixbuf", "pango", "cairo", "libepoxy",
# Las mismas variantes `-shared` que usa gtk3 (2026-09-05). No es simetría: declarar acá las
# ESTÁTICAS junto a un gtk3 que trae las compartidas son dos artefactos peleando por el mismo
# `lib/pkgconfig/pango.pc` y las mismas cabeceras, que es la otra forma conocida de este mismo
# fallo. Van las dos listas al mismo sitio o ninguna.
"gtk3", "atk", "gdk-pixbuf-shared", "pango-shared", "cairo-shared", "libepoxy",
"glib-shared", "pcre2-shared", "libffi-shared", "zlib-shared",
"harfbuzz", "fribidi", "freetype-shared", "fontconfig-shared", "pixman",
"harfbuzz-shared", "fribidi", "freetype-shared", "fontconfig-shared", "pixman",
"libpng-shared", "libjpeg-turbo-shared",
"wayland", "wayland-protocols", "libxkbcommon", "mesa", "libdrm",
"dbus", "pipewire", "pulseaudio", "alsa-lib",
+36
View File
@@ -0,0 +1,36 @@
# gdk-pixbuf-shared 2.44.6 — variante DINÁMICA. **Existe por un fallo medido, no por simetría.**
#
# El canónico (`recipes/gdk-pixbuf.toml`) es `-Ddefault_library=static`, así que quien lo enlaza se lo
# traga entero. Y `gtk3` produce DOS objetos compartidos —`libgtk-3.so` y `libgdk-3.so`—, de modo
# que cada uno se llevaba su propia copia. Los dos se cargan siempre juntos (libxul los declara
# NEEDED a los dos) ⇒ dos copias en un proceso, y el navegador moría antes de pintar:
#
# GLib-GObject-CRITICAL: cannot register existing type 'PangoFontMap'
# … decenas de líneas … tipo '<invalid>'
#
# Se midió con `nm -D --defined-only` sobre cada `.so` del rootfs, preguntando quién DEFINE
# `pango_font_map_get_type` / `cairo_create` / `gdk_pixbuf_get_type` / `hb_buffer_create`.
# Respuesta: `libgtk-3.so` Y `libgdk-3.so`, las dos. Debía ser una sola librería, y ninguna de ellas.
#
# Es la misma regla que ya arrastraba el corpus desde GTK4 y que la cadena GTK3 se había saltado:
# **las deps de una `.so` van a las variantes `-shared`, en lugar de las estáticas y jamás junto a
# ellas** (las dos instalan los mismos `.pc` y cabeceras).
#
# Sólo cambia el modo de librería: se conservan TODOS los switches del canónico para no arrastrar
# deps nuevas ni cambiar qué se construye.
name = "gdk-pixbuf-shared"
version = "2.44.6"
license = "LGPL-2.1-or-later"
[source]
tarball = "https://download.gnome.org/sources/gdk-pixbuf/2.44/gdk-pixbuf-2.44.6.tar.xz"
sha256 = "140c2d0b899fcf853ee92b26373c9dc228dbcde0820a4246693f4328a27466fa"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "dynamic"
[build.phases]
configure = "PKG_CONFIG_PATH=/usr/lib/pkgconfig PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release --wrap-mode=nodownload -Ddefault_library=shared -Dpng=enabled -Djpeg=disabled -Dtiff=disabled -Dgif=disabled -Dothers=disabled -Dglycin=disabled -Dbuiltin_loaders=png -Dgio_sniffing=false -Dman=false -Dintrospection=disabled -Dtests=false -Dinstalled_tests=false -Dgtk_doc=false -Dc_args=-Wno-error=date-time"
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", "glib-shared", "libpng-shared", "libffi-shared", "pcre2-shared", "zlib-shared"]
+12 -2
View File
@@ -69,9 +69,19 @@ install = "PYTHONPATH=/usr/lib/python3.12/site-packages DESTDIR=/out meson insta
# `lib/pkgconfig/glib-2.0.pc`. Una u otra, jamás las dos.
build = [
"meson", "samurai", "python3", "pkgconf",
"atk", "gdk-pixbuf", "pango", "cairo", "libepoxy",
# ── 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", "fribidi", "freetype-shared", "fontconfig-shared", "pixman",
"harfbuzz-shared", "fribidi", "freetype-shared", "fontconfig-shared", "pixman",
"libpng-shared", "libjpeg-turbo-shared", "libtiff-shared",
"wayland", "wayland-protocols", "libxkbcommon",
"libxml2-shared", "mesa", "libdrm",
+36
View File
@@ -0,0 +1,36 @@
# harfbuzz-shared 14.2.1 — variante DINÁMICA. **Existe por un fallo medido, no por simetría.**
#
# El canónico (`recipes/harfbuzz.toml`) es `-Ddefault_library=static`, así que quien lo enlaza se lo
# traga entero. Y `gtk3` produce DOS objetos compartidos —`libgtk-3.so` y `libgdk-3.so`—, de modo
# que cada uno se llevaba su propia copia. Los dos se cargan siempre juntos (libxul los declara
# NEEDED a los dos) ⇒ dos copias en un proceso, y el navegador moría antes de pintar:
#
# GLib-GObject-CRITICAL: cannot register existing type 'PangoFontMap'
# … decenas de líneas … tipo '<invalid>'
#
# Se midió con `nm -D --defined-only` sobre cada `.so` del rootfs, preguntando quién DEFINE
# `pango_font_map_get_type` / `cairo_create` / `gdk_pixbuf_get_type` / `hb_buffer_create`.
# Respuesta: `libgtk-3.so` Y `libgdk-3.so`, las dos. Debía ser una sola librería, y ninguna de ellas.
#
# Es la misma regla que ya arrastraba el corpus desde GTK4 y que la cadena GTK3 se había saltado:
# **las deps de una `.so` van a las variantes `-shared`, en lugar de las estáticas y jamás junto a
# ellas** (las dos instalan los mismos `.pc` y cabeceras).
#
# Sólo cambia el modo de librería: se conservan TODOS los switches del canónico para no arrastrar
# deps nuevas ni cambiar qué se construye.
name = "harfbuzz-shared"
version = "14.2.1"
license = "MIT"
[source]
tarball = "https://github.com/harfbuzz/harfbuzz/releases/download/14.2.1/harfbuzz-14.2.1.tar.xz"
sha256 = "a54a5d8e9380a41fbb762ce367bcbf7704792dfca0d93f1bbca86c5a57902e0e"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "dynamic"
[build.phases]
configure = "PKG_CONFIG_PATH=/usr/lib/pkgconfig PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release -Ddefault_library=shared -Dglib=enabled -Dgobject=disabled -Dcairo=disabled -Dicu=disabled -Dgraphite=disabled -Dfreetype=enabled -Dtests=disabled -Ddocs=disabled -Dintrospection=disabled -Dutilities=disabled"
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", "freetype-shared", "glib-shared", "pcre2-shared", "libffi-shared", "zlib-shared", "libpng-shared"]
+40
View File
@@ -0,0 +1,40 @@
# pango-shared 1.57.1 — variante DINÁMICA. **Existe por un fallo medido, no por simetría.**
#
# El canónico (`recipes/pango.toml`) es `-Ddefault_library=static`, así que quien lo enlaza se lo
# traga entero. Y `gtk3` produce DOS objetos compartidos —`libgtk-3.so` y `libgdk-3.so`—, de modo
# que cada uno se llevaba su propia copia. Los dos se cargan siempre juntos (libxul los declara
# NEEDED a los dos) ⇒ dos copias en un proceso, y el navegador moría antes de pintar:
#
# GLib-GObject-CRITICAL: cannot register existing type 'PangoFontMap'
# … decenas de líneas … tipo '<invalid>'
#
# Se midió con `nm -D --defined-only` sobre cada `.so` del rootfs, preguntando quién DEFINE
# `pango_font_map_get_type` / `cairo_create` / `gdk_pixbuf_get_type` / `hb_buffer_create`.
# Respuesta: `libgtk-3.so` Y `libgdk-3.so`, las dos. Debía ser una sola librería, y ninguna de ellas.
#
# Es la misma regla que ya arrastraba el corpus desde GTK4 y que la cadena GTK3 se había saltado:
# **las deps de una `.so` van a las variantes `-shared`, en lugar de las estáticas y jamás junto a
# ellas** (las dos instalan los mismos `.pc` y cabeceras).
#
# ⚠ `fribidi` y `pixman` siguen siendo estáticos acá: no existe variante `-shared` de ninguno de
# los dos y, al quedar embebidos en UNA sola `.so`, no hay copia duplicada que colisione. Es deuda
# anotada, no un olvido — si algún día otra `.so` del cierre también los embebe, vuelve el cuadro.
#
# Sólo cambia el modo de librería: se conservan TODOS los switches del canónico para no arrastrar
# deps nuevas ni cambiar qué se construye.
name = "pango-shared"
version = "1.57.1"
license = "LGPL-2.0-or-later"
[source]
tarball = "https://download.gnome.org/sources/pango/1.57/pango-1.57.1.tar.xz"
sha256 = "e65d6d117080dc3aeeb7d8b4b3b518f7383aa2e6cfce23117c623cd624764c2f"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "dynamic"
[build.phases]
configure = "PKG_CONFIG_PATH=/usr/lib/pkgconfig PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release --wrap-mode=nodownload -Ddefault_library=shared -Dc_args=-Wno-error=date-time -Dintrospection=disabled -Dgtk_doc=false -Dbuild-testsuite=false -Dbuild-examples=false"
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", "cairo-shared", "harfbuzz-shared", "fribidi", "glib-shared", "freetype-shared", "fontconfig-shared", "pixman", "libpng-shared", "expat-shared", "libffi-shared", "pcre2-shared", "zlib-shared"]
+38
View File
@@ -0,0 +1,38 @@
# ══ PROMOVIDA AL CORPUS DESDE LAS COLAS (2026-09-05) ═══════════════════════════════════════════
# Esta receta existía IDÉNTICA en las cuatro colas de escritorio (incoming-{kde,gnome,wlr,cosmic}):
# un solo md5 entre las cuatro, verificado antes de mover. Sube al corpus por la misma razón que
# `mpv`: una receta resuelve sibling-first y después el catálogo PADRE, nunca una cola hermana, así
# que lo que comparten varias imágenes tiene que vivir acá o no lo alcanzan.
#
# Lo destapó `atuq`, que vive en el corpus y por eso no podía llegar a ninguna de las cuatro copias.
# El síntoma es el mismo que ya cita el perfil de sway en `targets.toml`, y el navegador ni siquiera
# llega a pintar:
# xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb
#
# Las copias de las colas se dejan donde están A PROPÓSITO: resuelven sibling-first, o sea que
# siguen usando la suya, con el MISMO ArtifactHash ⇒ cero rebuilds y cero riesgo para las cuatro
# imágenes ya cerradas. Barrerlas es otra unidad de trabajo, no un efecto colateral de ésta.
# xkeyboard-config 2.44 — datos de layouts de teclado XKB + `xkeyboard-config.pc` (variable xkb_base).
# plasma-desktop lo EXIGE en ConfigureChecks (pkg_get_variable xkb_base) y kwin/Qt-wayland lo usan en
# runtime (/usr/share/X11/xkb; sin él: "xkbcommon: failed to add default include path /usr/share/X11/xkb").
# Meson, sin compilación real (instala datos + .pc). nls off (evita gettext); sin libxml2 (validación).
name = "xkeyboard-config"
version = "2.44"
license = "MIT"
[source]
tarball = "https://www.x.org/releases/individual/data/xkeyboard-config/xkeyboard-config-2.44.tar.xz"
sha256 = "54d2c33eeebb031d48fa590c543e54c9bcbd0f00386ebc6489b2f47a0da4342a"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "dynamic"
[build.phases]
configure = "meson setup output --prefix=/usr -Dnls=false -Dcompat-rules=false"
compile = "ninja -C output"
install = "DESTDIR=/out ninja -C output install"
[deps]
build = ["meson", "samurai", "python3", "pkgconf"]
+5 -1
View File
@@ -36,7 +36,11 @@ URL="${URL:-about:support}"
RAICES="atuq gtk3 atk gdk-pixbuf pango cairo libepoxy glib-shared pcre2-shared libffi-shared
zlib-shared harfbuzz fribidi freetype-shared fontconfig-shared pixman libpng-shared
libjpeg-turbo-shared wayland libxkbcommon mesa libdrm dbus pipewire pulseaudio alsa-lib
libxml2-shared dejavu-fonts"
libxml2-shared dejavu-fonts
xkeyboard-config"
# `xkeyboard-config` son DATOS, no una librería, y sin ellos el navegador ni pinta:
# xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb
# Es el mismo modo de fallo silencioso que las fuentes: nada en la clausura lo ve venir.
# ── EL ROOTFS SE REVALIDA POR HASH, NO POR EXISTENCIA ──────────────────────────────────────────
# «Ya está hidratado» es la pregunta equivocada: tras cualquier re-hash del corpus el directorio