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>
40 lines
2.4 KiB
TOML
40 lines
2.4 KiB
TOML
# GNU make 4.4.1 — primera pieza del toolchain hammer-from-source (SDD 11 §7.2b).
|
|
#
|
|
# Arranca el reemplazo, una a una, de las herramientas que hoy el builder toma de Alpine
|
|
# (`/toolchain`) por recetas hammer construidas desde fuente. `make` es la pieza base: todas las
|
|
# demás recetas autotools (musl, busybox, el propio grep) la invocan en su fase de compile/install.
|
|
#
|
|
# Build estático con `zig cc` cross al target, mismo camino ya probado con `grep` 3.12: el tarball
|
|
# release trae `configure` generado (AutoconfReady → ./configure && make && make install), así que no
|
|
# hay `./bootstrap` ni gnulib por red. `--disable-nls` evita gettext; sin guile (opcional, ausente).
|
|
# El sha256 del tarball es identificador inmutable, pinned igual de fuerte que un commit (ADR 0006).
|
|
|
|
name = "make"
|
|
version = "4.4.1"
|
|
license = "GPL-3.0-or-later"
|
|
|
|
[source]
|
|
tarball = "https://ftp.gnu.org/gnu/make/make-4.4.1.tar.gz"
|
|
sha256 = "dd16fb1d67bfab79a72f5e8390735c49e3e8e70b4945a15ab1f81ddb78658fb3"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
# `--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"]
|