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.
This commit is contained in:
Reference in New Issue
Block a user