From e568f7714b93f40a6468e6701b65b280cdd6bfe6 Mon Sep 17 00:00:00 2001 From: sergio Date: Fri, 17 Jul 2026 09:45:22 -0400 Subject: [PATCH] =?UTF-8?q?matar-gcc:=20el=20doc=20de=20deuda=20dec=C3=ADa?= =?UTF-8?q?=2047=20recetas;=20son=2016=20(recontado=20parseando=20TOML)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Eran 47 el 2026-07-16. Desde entonces se migraron 31 y nadie actualizó el doc, así que el frente se leía 3x más grande de lo que es. Recontado hoy: 16 = 4 C (file/libgcrypt/libsodium/linux-pam) + 12 Rust con sys-crate C. CÓMO CONTAR, documentado en el doc: NO con grep. `grep -l 'compiler = "gcc"' recipes/*.toml` da 18 — cuenta bzip2 y pigz, que ya son zig-cc y sólo MENCIONAN gcc en un comentario. El grep no distingue campo de comentario; hay que parsear el TOML. (Me comí ese error yo mismo antes de medirlo bien.) Y la otra dirección también engaña: pigz DECLARABA zig-cc y construía con gcc igual (7d86dbf) — la receta dice la intención, harkaq dice el hecho. xplr estaba mal clasificada como 'C puro': es Rust (embebe mlua-sys, que compila Lua en C). LO QUE IMPORTA — las 12 Rust no son 12 problemas, son uno: bajo zig-cc el link falla con símbolos de unwinding sueltos (_Unwind_GetCFA/_Unwind_DeleteException) que aporta libgcc. La deuda no es 'zig miscompila 12 programas', es 'falta un runtime de unwinding para el C de los sys-crates'. Y converge con el frente static: helix y tuc salían dinámicas arrastrando libgcc_s.so.1 de Alpine DENTRO del binario — la misma libgcc, la misma razón, medida en runtime en vez de en build. Un fix del unwinding cerraría los dos frentes a la vez. Precedente: cmake se arregló con -static-libstdc++ -static-libgcc. Co-Authored-By: Claude Opus 4.8 --- .../deuda-compilador-matar-gcc.md | 94 +++++++++++-------- 1 file changed, 54 insertions(+), 40 deletions(-) diff --git a/tandas/needs-review-harkaq/deuda-compilador-matar-gcc.md b/tandas/needs-review-harkaq/deuda-compilador-matar-gcc.md index 977a9ca1..d6e4dc36 100644 --- a/tandas/needs-review-harkaq/deuda-compilador-matar-gcc.md +++ b/tandas/needs-review-harkaq/deuda-compilador-matar-gcc.md @@ -3,58 +3,72 @@ harkaq clasificaba `/usr/bin/gcc` como sonda esperada SIEMPRE, así que marcaba estas recetas `Hermetico` — ciego a que dependen del gcc de Alpine (`compiler=gcc` = CC=gcc de Alpine, musl+GNU ld). El arreglo (harkaq-suggest, 2026-07-16): para `compiler=gcc` los frontends de gcc son DEUDA -DE COMPILADOR, no sonda. Esto redimensiona matar-gcc de "{kernel, cmake}" a **47 recetas**. +DE COMPILADOR, no sonda. Cada una compila con gcc porque zig-cc la miscompila/no la soporta (documentado en su receta). **Acción por receta:** migrar a zig-cc cuando zig mejore, o aceptar el escape como deuda conocida. -## C puro (36) — candidatas a zig cuando zig mejore - - bzip2 - - expat - - curl - - file - - freetype - - gzip - - htop - - json-c - - jq - - less - - libevent - - libgcrypt - - libgpg-error - - libssh2 - - libffi - - libassuan - - libxml2 - - libevdev - - linux-pam - - libpng - - libsodium - - libyaml - - libuv - - mtdev - - nano - - pigz - - pcre2 - - procps-ng - - socat - - tig - - tmux - - vim - - wget - - xplr - - xz - - zstd +## Estado real: 16 recetas (2026-07-17) + +Este doc decía **47**. Eran 47 el 2026-07-16; desde entonces se migraron 31 y nadie lo actualizó, +así que el frente se leía 3× más grande de lo que es. Recontado hoy. + +**CÓMO CONTAR — no uses grep.** `grep -l 'compiler *= *"gcc"' recipes/*.toml` da **18**: cuenta +`bzip2` y `pigz`, que ya son zig-cc y sólo *mencionan* gcc en un comentario. El grep no distingue +campo de comentario. Contá parseando el TOML: + +```sh +python3 - <<'PY' +import tomllib, glob, os +for f in sorted(glob.glob('recipes/*.toml')): + try: d = tomllib.load(open(f, 'rb')) + except Exception: continue + if d.get('build', {}).get('compiler') == 'gcc': + print(os.path.basename(f)[:-5]) +PY +``` + +**Y ojo con la otra dirección**: declarar `zig-cc` no prueba que construya con zig-cc. `pigz` +*declaraba* zig-cc y construía con gcc igual (7d86dbf) — lo cazó harkaq midiendo el build, no +leyendo la receta. La receta dice la intención; **harkaq dice el hecho**. Este doc lista lo +declarado; para lo real, medí. + +## C (4) + + - file — link=static + - libgcrypt — link=static + - libsodium — link=static + - linux-pam — link=dynamic + +## Rust con sys-crate C (12) — gcc para el C embebido (libgit2-sys, mlua-sys, etc) -## Rust con sys-crate C (11) — gcc para el C embebido (libgit2-sys, etc) - broot - cargo-audit - cargo-cache - delta - - gitui - git-absorb + - gitui - helix - hurl - ouch + - xplr - yazi - zellij + +`xplr` estaba mal clasificada acá como "C puro": es Rust (embebe `mlua-sys`, que compila Lua en C). + +## La raíz de las 12 Rust: el runtime de UNWINDING de libgcc + +Las 12 no son 12 problemas, son uno. Su receta lo dice (ej. `xplr`): bajo zig-cc el link falla con +símbolos de unwinding sueltos (`_Unwind_GetCFA`, `_Unwind_DeleteException`) que aporta **libgcc**; +`compiler="gcc"` usa el musl-gcc de Alpine, que trae ese runtime. O sea: la deuda no es "zig +miscompila 12 programas", es "falta un runtime de unwinding para el C de los sys-crates". + +**Converge con el frente `static`** (`scripts/static-audit.sh`, 2026-07-17): `helix` y `tuc` salían +dinámicas arrastrando **`libgcc_s.so.1` de Alpine dentro del binario final** — la misma libgcc, por +la misma razón, pero medida en runtime en vez de en build. Es deuda de matar-gcc que ninguna +declaración registra, invisible hasta que se midió. Un fix del unwinding cerraría las dos a la vez. + +Precedente de que se puede: el artefacto de `cmake` arrastraba `libstdc++`/`libgcc_s` de Alpine a +cada build que lo declaraba como dep, y `-static-libstdc++ -static-libgcc` lo dejó con NEEDED sólo +`libc.musl`.