From c9c6727c3bf10b454cb67af2968dafbec6791f94 Mon Sep 17 00:00:00 2001 From: Sergio Date: Sat, 5 Sep 2026 09:53:17 +0000 Subject: [PATCH] =?UTF-8?q?atk:=20a=20las=20variantes=20`-shared`=20?= =?UTF-8?q?=E2=80=94=20su=20`.so`=20llevaba=20una=20copia=20entera=20de=20?= =?UTF-8?q?GObject=20adentro?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Al abrir el primer atuq en pantalla, murió así: GLib-GObject-CRITICAL: cannot register existing type 'gpointer' … 45 líneas iguales … Segmentation fault (exit 139) El síntoma no nombra a atk por ningún lado, y las dos glib no estaban como dos ficheros en el rootfs —había UNA sola libgobject—. La segunda copia estaba EMBEBIDA: `atk` declaraba la variante ESTÁTICA de glib y produce un objeto compartido, así que el enlazador le metió GObject entero dentro de `libatk-1.0.so`. Todo proceso que cargue atk y libgobject a la vez —o sea cualquier app GTK— acaba con dos sistemas de tipos peleando. SE ENCONTRÓ MIDIENDO, NO LEYENDO: `nm -D --defined-only` sobre cada `.so` del rootfs, buscando quién DEFINE `g_type_register_static`. Dos respuestas: `libgobject-2.0.so`, que debe, y `libatk-1.0.so`, que no. Es la regla que el corpus ya tenía escrita desde GTK4 y que esta receta se saltó: las deps de una `.so` van a las variantes `-shared` EN LUGAR DE las estáticas, nunca junto a ellas. RADIO MEDIDO ANTES DE TOCAR (`yupana radio atk`): 4 transitivos, 3 sellados caen a deuda — atk, gtk3 y firefox. GNOME NO está en el radio: usa gtk4. El costo es un rebuild de firefox de cuatro horas, y no hay forma de esquivarlo: sin esto el navegador no abre. Esto es «sellado ≠ usable» otra vez, y la única razón por la que apareció es que alguien lo ABRIÓ en una pantalla. La clausura decía 100%. --- recipes/atk.toml | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/recipes/atk.toml b/recipes/atk.toml index 43ff64a8..c89824ee 100644 --- a/recipes/atk.toml +++ b/recipes/atk.toml @@ -41,4 +41,20 @@ 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", "pcre2", "libffi", "zlib"] +# ══ LAS VARIANTES `-shared`, Y NO LAS ESTÁTICAS — MEDIDO EL 2026-09-05 ═════════════════════════ +# `atk` produce un OBJETO COMPARTIDO (`libatk-1.0.so`). Con la glib estática, el enlazador absorbe +# GObject ENTERO dentro de esa `.so`, y entonces todo proceso que cargue atk y libgobject a la vez +# tiene DOS sistemas de tipos de GObject compitiendo. No es teoría: así murió el primer atuq que se +# intentó abrir, y el síntoma no nombra a atk por ningún lado — +# +# GLib-GObject-CRITICAL: cannot register existing type 'gpointer' +# … 45 líneas … Segmentation fault (exit 139) +# +# Se encontró midiendo, no leyendo: `nm -D --defined-only` sobre cada `.so` del rootfs buscando +# quién DEFINE `g_type_register_static`. Salieron dos: `libgobject-2.0.so` (que debe) y +# `libatk-1.0.so` (que no). +# +# Es la regla que el corpus ya tenía escrita desde GTK4: las deps de una `.so` van a las variantes +# `-shared` **en lugar de** las estáticas, jamás junto a ellas (las dos instalan los mismos `.pc` y +# cabeceras, así que declarar ambas son dos artefactos peleando por el mismo fichero). +build = ["meson", "samurai", "python3", "pkgconf", "glib-shared", "pcre2-shared", "libffi-shared", "zlib-shared"]