sergio/takana

Etapa G: broot + pueue al corpus (85->87) — NO había deadlock de link, era lento + impaciencia

Investigué la hipótesis del "deadlock de link de zig-cc" en binarios Rust grandes
(broot/pueue/starship). RESULTADO: NO HAY DEADLOCK. La evidencia:

- pueue construye+corre con zig-cc PURO (sin gcc): selló dc735889, pueue 4.0.4. En la
  granja lo había matado a los 192s creyéndolo colgado — era rustc al 99% en codegen
  del crate final (cargo no imprime durante el codegen de una sola crate grande), +
  contención de 4 workers en 8 cores. Con paciencia y sin contención, completa.
- broot construye+corre (broot 1.57.0, static). Necesita compiler=gcc SÓLO por su
  libgit2-sys (cc-rs compila C que zig rechaza — el gueto gcc ya commiteado); el LINKER
  zig anda bien, sólo es lento por el codegen del binario grande.

Probé además linker=gcc (la hipótesis) y SÍ funcionaba, pero lo REVERTÍ: (1) estaba
basado en un diagnóstico equivocado (no hay deadlock); (2) era DAÑINO para la
reproducibilidad — delta/gitui se publicaron con linker=zig, y el linker NO entra al
artifact_hash (es código del lab, no de la receta) => un binario distinto bajo el mismo
hash => cache-hit que enmascara la divergencia. Borré el broot construido con
gcc-linker del store y lo reconstruí con el código commiteado (linker=zig) => el broot
publicado (257415a8) ahora ES reproducible con el lab tal como está en git.

recetas: broot (compiler=gcc+zlib por libgit2-sys, linker zig) y pueue (zig puro)
promovidas incoming/->recipes/. Publicadas al repo firmado (87). El lab queda INTACTO.

LECCIÓN para la granja: subir el timeout/no matar builds de binarios Rust grandes
(>192s de codegen es NORMAL, no deadlock); distinguir colgado de lento por CPU del
rustc (0% = problema, 99% = trabajando), no por silencio del log de cargo.

edda3a742a344d1419e5bad4e20d3d37e761bb62 · ruwaq sergio · 2026-06-21T21:12:49Z (4 killa ñawpaq) · tayta 640198dab · kay commitpi sach'ata qhaway