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%.
GTK3 no existía en NINGUNA cola y es el único toolkit de Gecko en Linux. Como
Waterfox y Zen son forks de Gecko, los tres navegadores consumen exactamente esta
misma pieza: una receta sostiene a los tres. Por eso va al CORPUS y no a una cola
—una receta resuelve sibling-first y después el catálogo padre, nunca una cola
hermana—, que es la lección de mpv y justo lo que OBS no pudo cumplir al quedar
atado a incoming-kde por Qt6. La plataforma nace bien puesta para que los tres
navegadores no repitan ese error.
Al medir el cierre antes de escribir, TODO estaba ya en el corpus salvo `atk`. Un
ladrillo chico destrabando una pieza grande: por eso atk fue primero.
WAYLAND-ONLY de verdad, no de intención: -Dx11_backend=false. A diferencia de OBS
—que exigía find_package(X11) incondicional— GTK3 sí deja apagarlo, y eso saca
libX11/libXext/libXi/libXrandr/… del cierre. Esa cadena vive sólo en incoming-kde
y meterla en el corpus la pondría en las CINCO imágenes.
Verificado en el artefacto: los .pc son gdk-wayland-3.0 y gtk+-wayland-3.0 (no hay
gdk-x11-3.0), libgtk-3.so.0 no enlaza X11 ni xcb, y libgdk-3.so trae NEEDED
libwayland-client/cursor/egl + libxkbcommon.
⚠ Consecuencia escrita en la receta: un Firefox contra este GTK3 no correrá como
cliente X11 ni bajo Xwayland. Bajo Wayland nativo sí. Es la postura de la distro
aplicada al navegador, no un accidente.
Las deps van a las variantes -shared EN LUGAR DE las estáticas, nunca junto a
ellas: libgtk-3.so es un objeto compartido y un .a sin PIC adentro da
`relocation R_X86_64_32 against png_default_write_data`. Se sustituye y no se suma
porque ambas variantes instalan los MISMOS .pc y cabeceras — declarar las dos
serían dos artefactos peleando por lib/pkgconfig/glib-2.0.pc.
Sergio