Files
takana/recipes/incoming-wlr/gdk-pixbuf.toml
T
SergioandClaude Opus 5 2b4999f682 libpng-pic: la variante que faltaba entre la estatica y la .so
gdk-pixbuf no sellaba, y las dos libpng del corpus fallaban por extremos
OPUESTOS — probadas las dos hoy, una detras de otra:

  libpng         .a sin PIC   → «relocation R_X86_64_64 cannot be used against
                                local symbol; recompile with -fPIC», porque ese
                                link acaba siendo dinamico (aparece libc.so)
                                pese al `link = "static"` de la receta.
  libpng-shared  solo la .so  → «unable to find static system library 'png16'»,
                                porque la receta pide --prefer-static.

Es la misma tenaza que el `bz2` de freetype: los -dev traen .so pero no .a. La
salida no es elegir un extremo sino una .a que TAMBIEN sea PIC. `libpng-pic` es
copia literal del canonico con `--with-pic` en el configure; nada mas.

EVIDENCIA de que es PIC, y hay que medirla bien: 0 relocs R_X86_64_32/32S
contra 706 del canonico — EXCLUYENDO las secciones .debug_*. Sin ese filtro
ambas dan >13000 y parecen identicas; es la correccion de la regla del .a
no-PIC que ya nos mordio en GNOME.

El canonico NO se toca (decision del usuario): 12 dependientes en cuatro colas
y es estatico por diseño. Se añade una SOMBRA en incoming-wlr que cambia una
sola linea de deps. libpng-pic si va al corpus, porque la resolucion es
HERMANO→PADRE y una receta del corpus no veria una variante en incoming-*.

⚠ ALCANCE: la sombra la ve su cola. gtk4, libadwaita, gtksourceview y otras 4
son del CORPUS y siguen resolviendo el gdk-pixbuf canonico roto.

⚠ NO ERA UN FALLO NUEVO: gdk-pixbuf tenia artefacto sellado y se servia por
cache-hit. La reconstruccion no lo rompio, lo DESTAPO.

Verificado: sombra SELLADA, 71 MB, con .a, .pc y los loaders .so reales — no un
directorio vacio haciendose pasar por artefacto.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xd5DComN9Nu47TBpYMBHBn
2026-08-21 13:08:49 +00:00

42 lines
3.1 KiB
TOML

# gdk-pixbuf 2.44.6 — SOMBRA de `recipes/gdk-pixbuf.toml` para la cola wlr/sway.
#
# ── QUÉ CAMBIA Y POR QUÉ ────────────────────────────────────────────────────────────────────────
# UNA sola línea: `libpng` → `libpng-shared` en `[deps]`. El resto es copia literal del canónico.
#
# El canónico muere enlazando:
# ld.lld: error: relocation R_X86_64_64 cannot be used against local symbol; recompile with -fPIC
# >>> in archive /usr/lib/libpng16.a
# y en la misma tanda de errores aparece `libc.so`, o sea que ESE link acabó siendo DINÁMICO pese a
# que la receta declara `link = "static"`. Con un link dinámico, una `.a` sin PIC no se puede usar:
# `recipes/libpng.toml` es `--disable-shared` y sus objetos no son PIC. `libpng-shared` existe
# justamente para este caso — su cabecera lo dice: «no enlaza dentro de un .so».
#
# ⚠ NO ES UN FALLO NUEVO: es una REGRESIÓN CONGELADA que la reconstrucción destapa. gdk-pixbuf tenía
# artefacto sellado y se servía por cache-hit, así que el fallo llevaba tiempo invisible. Es el mismo
# patrón que documenta la campaña del lab: «no re-hashea nada sellado» ≠ «es seguro».
#
# ── POR QUÉ SOMBRA Y NO TOCAR EL CANÓNICO ───────────────────────────────────────────────────────
# Decisión del usuario (2026-08-21). El canónico tiene 12 dependientes en cuatro colas y es estático
# por diseño; cambiarle la dep es una decisión de arquitectura del corpus, no un arreglo de receta.
# Mismo patrón que la sombra de libadwaita en incoming-gnome.
#
# ⚠ ALCANCE REAL, y hay que tenerlo presente: la resolución de deps es HERMANO→PADRE — una receta del
# CORPUS no ve las de `incoming-*`. Así que esta sombra la usan las recetas de ESTA cola, y las 7 del
# corpus (gtk4, libadwaita, gtksourceview…) siguen resolviendo el canónico roto.
name = "gdk-pixbuf"
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 = "static"
[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 --prefer-static -Ddefault_library=static -Dpng=enabled -Djpeg=disabled -Dtiff=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", "libpng-pic", "libffi", "pcre2", "zlib"]