make: --disable-load — sin esto el binario sale DINAMICO Y ROTO y tumba el corpus

Sintoma: al reconstruir el corpus, bash/binutils/bison/busybox/zlib morian
con exit 139. dmesg lo nombraba: `traps: make general protection fault in
ld-musl-x86_64.so.1`.

Causa exacta, leida de la linea de link real:

  hammer-zig-cc -g -O2 -Wl,--export-dynamic -static -o make src/*.o

GNU make 4.4.1 soporta cargar objetos en runtime (directiva `load`), asi que
su configure anade -Wl,--export-dynamic. El wrapper hammer-zig-cc tiene la
regla —correcta— de que `-static` CEDE ante cualquier link que exija dinamico,
y --export-dynamic es uno de esos marcadores ⇒ le quitaba el -static y se
sellaba un make dinamico que segfaultea. Como toda receta autotools invoca
make, se propagaba a casi todo el corpus.

El arreglo va en la receta y NO en el wrapper: el conflicto es de origen
—pedimos estatico de un proyecto que pide symtab dinamica para una funcion
que no usamos—. Ensenarle al wrapper a ignorar --export-dynamic lo romperia
para gobject-introspection, que si lo necesita.

POR QUE NO SE VIO ANTES, que es la leccion: el artefacto viejo de make era
estatico y estaba congelado por cache-hit, probablemente desde antes de que
existiera esa regla del wrapper. Nadie lo reconstruyo hasta que el corpus se
re-hasheo entero. Un cambio que "no re-hashea nada sellado" igual cambia lo
que producen los builds FUTUROS, y eso queda invisible hasta que algo fuerza
la reconstruccion.

Verificado: make ESTATICO, corre (GNU Make 4.4.1), y zlib —que fallaba con
139— sella.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

98a958ec480f3c986219f2ba353768ba72168cf1 · by Sergio · 2026-08-10T20:37:49Z (2 months ago) · parent 05e8ba853 · browse the tree at this commit

Semantic delta

No definition changed: this change is text, documentation or data.

1 files · +16 −1

recipes/make.toml +16 −1

diff --git a/recipes/make.toml b/recipes/make.toml
index 9bbef4ce..92431bd5 100644
--- a/recipes/make.toml
+++ b/recipes/make.toml
@@ -21,4 +21,19 @@ sha256  = "dd16fb1d67bfab79a72f5e8390735c49e3e8e70b4945a15ab1f81ddb78658fb3"
 compiler = "zig-cc"
 target   = "x86_64-linux-musl"
 link     = "static"
-flags    = ["--disable-nls"]
+# `--disable-load` NO es cosmético: sin él este binario sale DINÁMICO Y ROTO, y se lleva por delante
+# medio corpus (2026-08-10). GNU make soporta cargar objetos en runtime (la directiva `load`), así
+# que su configure añade `-Wl,--export-dynamic` al link. El wrapper `hammer-zig-cc` tiene la regla
+# —correcta— de que `-static` CEDE ante cualquier link que exija dinámico, y `--export-dynamic` es
+# uno de esos marcadores ⇒ le quitaba el `-static` y sellaba un `make` dinámico que segfaultea en
+# `ld-musl` (exit 139). Como TODA receta autotools invoca make, el fallo se propagaba a todo.
+#
+# El arreglo va acá y no en el wrapper: el conflicto es de origen —pedimos un binario estático de un
+# proyecto que pide symtab dinámica para una función que no usamos—. Enseñarle al wrapper a ignorar
+# `--export-dynamic` lo rompería para gobject-introspection, que sí lo necesita de verdad.
+#
+# POR QUÉ NO SE VIO ANTES: el artefacto viejo de `make` era estático y estaba congelado por
+# cache-hit, quizá desde antes de que existiera esa regla del wrapper. Nadie lo reconstruyó hasta
+# que el corpus se re-hasheó entero. Un cambio que "no re-hashea nada" igual cambia lo que producen
+# los builds FUTUROS, y eso no se nota hasta que algo fuerza la reconstrucción.
+flags    = ["--disable-nls", "--disable-load"]