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

recipes/incoming-wlr/gdk-pixbuf.toml

@@ -0,0 +1,41 @@
+# 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"]

recipes/libpng-pic.toml

@@ -0,0 +1,40 @@
+# libpng-pic 1.6.58 — variante ESTÁTICA pero PIC (`libpng16.a` compilada con -fPIC).
+#
+# ── EL HUECO QUE LLENA, ENTRE EL CANÓNICO Y LA -shared ──────────────────────────────────────────
+# El corpus tenía dos libpng y ninguna sirve para el caso de gdk-pixbuf:
+#
+#   `libpng`         → `--disable-shared`, objetos SIN PIC. Si el link acaba siendo dinámico:
+#                      «relocation R_X86_64_64 cannot be used against local symbol; recompile with -fPIC».
+#   `libpng-shared`  → sólo `libpng16.so`. Si el consumidor pide estático (`--prefer-static`):
+#                      «unable to find static system library 'png16'».
+#
+# Las dos las probé con gdk-pixbuf el 2026-08-21 y fallan por los extremos opuestos. La salida no es
+# elegir un extremo, es una `.a` que TAMBIÉN sea PIC: satisface a quien pide la estática por nombre
+# y además se puede reubicar dentro de un link dinámico. Es la misma clase de muro que deja a CPython
+# sin `_curses` («relocation R_X86_64_PC32 against symbol 'stdscr'»), así que esta variante es un
+# primer ladrillo de ese frente, no un parche de una receta.
+#
+# ── QUÉ CAMBIA RESPECTO A `recipes/libpng.toml` ─────────────────────────────────────────────────
+# Sólo el `configure`: se añade `--with-pic` (autoconf/libtool: compila los objetos del archivo
+# estático con -fPIC). Nada más — mismo tarball, mismo sha256, mismo compilador, mismas deps.
+#
+# NO toca al canónico ni lo reemplaza: nombre distinto ⇒ sin colisión, igual que `libpng-shared`
+# (ver la nota de promoción ahí). Vive en el CORPUS, no en una cola, porque la resolución de deps es
+# HERMANO→PADRE: una receta del corpus no vería una variante metida en `incoming-*`.
+name    = "libpng-pic"
+version = "1.6.58"
+license = "Libpng"
+[source]
+tarball = "https://downloads.sourceforge.net/libpng/libpng-1.6.58.tar.gz"
+sha256  = "8c9b05b675ca7301a458df2c2e46f26e1d41ff36b8863f8c33530bc58c2e6225"
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "static"
+flags    = []
+[build.phases]
+configure = './configure --build=$CBUILD --host=$CHOST --prefix=/usr --disable-shared --enable-static --with-pic CPPFLAGS=-I/usr/include LDFLAGS=-L/usr/lib'
+compile   = 'make LDFLAGS="-all-static -no-pie" -j"$(nproc)"'
+install   = 'make DESTDIR=/out install LDFLAGS="-all-static -no-pie"'
+[deps]
+build = ["zlib", "make"]