Files
takana/recipes
sergioandClaude Opus 5 a79cc8d1ab gnome onda 3: gcr SELLADO (b3:698096b0) + p11-kit + las variantes shared de libgcrypt/libgpg-error
Tercera de la cima. gnome-shell la exige por gcr-4 (meson.build:74) y su JS importa gi://Gcr
(js/ui/components/keyring.js) ⇒ tenía que ser .so con typelib, no había opción estática.

Cadena nueva: p11-kit (b3:8dbec390) → gcr. p11-kit va con -Dtrust_module=disabled, que es lo
único que arrastraba libtasn1: una receta menos.

EL NUDO REAL fue el PIC, otra vez. libgcrypt y libgpg-error del corpus son estáticas SIN PIC
(y libgcrypt además está afinada para binarios -all-static -no-pie, con la advertencia escrita
de que el flag va en compile e install pero nunca en configure). Meterlas en un .so da
«relocation R_X86_64_32 ... recompile with -fPIC».

NO se tocaron las canónicas: `yupana radio` dio 5 sellados cayendo a deuda en base/cli, y
mostró además que existe OTRA libgpg-error en incoming-kde con 39 dependientes — justo el
tipo de colisión que el radio existe para ver. Se hicieron variantes -shared en la cola, que
es el idioma que este frente ya tiene (zlib-shared, cairo-shared, freetype-shared…).

libgcrypt-shared compiló con ZIG-CC, no gcc como la canónica: evidencia de que esa receta puede
migrar cuando le toque el turno de matar-gcc. Necesitó -fno-sanitize=undefined (el runtime UBSan
que inyecta zig deja __ubsan_handle_* sin definir en el .so), remedio ya documentado en zlib-shared.

Otros dos apagados de gcr, cada uno ahorrando una receta: -Dssh_agent=false (libsecret sólo la
pide el agente ssh) y -Dgpg_path fijo (gcr sólo quiere la RUTA de gpg para hornearla, no ejecuta
nada). Y el sed de subdir('po'): el msgfmt de gettext-tiny ABORTA con SIGABRT en po/ar.po. Es la
segunda vez que ese msgfmt marca el límite; si hay una tercera, conviene autorar el gettext de GNU.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-28 06:54:14 -04:00
..