Sergio
e852f48491
Barrido de TEXTO puro: 1427 líneas de comentario TOML. Cero ArtifactHash movidos, y eso está MEDIDO, no deducido: hasheé las 741 antes y después y los ficheros de hashes son idénticos byte a byte (723 con hash real + 18 que ya no hasheaban de antes). El guardián valió la pena: el primer barrido, filtrando por 'la línea empieza con #', movió el hash de helix, lsof y steam-runtime-sniper. La causa es que una fase se escribe como compile = <triple> ... <triple> y sus comentarios de SHELL también empiezan con #, pero viven dentro del VALOR — y las fases sí entran en hash_inputs. El barrido ahora calcula los rangos de las cadenas multilínea de TOML y no entra ahí. Quedan intactos a propósito: .hammer-zig-cc y .hammer-cargo-vendor (literales dentro de fases), hammerd, hammer-recover y toda ruta que empiece por /
47 lines
2.4 KiB
TOML
47 lines
2.4 KiB
TOML
# Importada de Alpine aports por `takana import-alpine` (Etapa G). PUNTO DE PARTIDA — pero
|
|
# YA trae los parches de musl de Alpine (lo que un import de nix pierde). Pendiente: el
|
|
# sha256 del tarball (el wrapper lo calcula), y adaptar build/install del shell de abuild.
|
|
name = "tuc"
|
|
version = "1.3.0"
|
|
license = "GPL-3.0-or-later"
|
|
|
|
[source]
|
|
tarball = "https://github.com/riquito/tuc/archive/v1.3.0/tuc-1.3.0.tar.gz"
|
|
# FIXME sha256: el wrapper lo calcula (Alpine publica sha512). sha512 de Alpine:
|
|
# sha512 = "da64cffa388d032576b1f96f13d20c1ee657cd99eba0d1b0252dcc133bcd5b2de49007a30c426760d845dbd5ddf23ab7b81ebb83bce4eba7f40d25712f539ddf"
|
|
sha256 = "81dc5f4a0355ecdf9515c88c34c365d20f339d316df7dbe72667cd2b18445c61"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
flags = ["--bin", "tuc"]
|
|
|
|
[build.phases]
|
|
# SIN fase `compile` custom — A PROPÓSITO (2026-07-17, frente static-audit).
|
|
#
|
|
# La receta importada de Alpine traía `cargo build --frozen --release`. Eso NO era inocente: en
|
|
# `resolve_phases` el lab sólo autogenera la fase si la receta NO la trae (`if out.compile.is_none()`),
|
|
# así que un `compile` propio REEMPLAZA el comando del lab ENTERO y con él se pierden las tres cosas
|
|
# que hacen honesto al `link = "static"`:
|
|
# 1. `-C target-feature=+crt-static` (mete musl DENTRO; sin esto el rust de Alpine enlaza dinámico)
|
|
# 2. `-C relocation-model=static` (ET_EXEC sin interpreter, en vez de PIE)
|
|
# 3. `-C linker=.hammer-zig-cc` (el wrapper que sanea el triple `x86_64-alpine-linux-musl`)
|
|
# El binario salía PIE dinámico con `NEEDED: libgcc_s.so.1, libc.musl-x86_64.so.1`.
|
|
#
|
|
# Ojo con el diagnóstico fácil: ese `libgcc_s` NO lo metía ningún sys-crate en C. tuc es Rust puro.
|
|
# Es el UNWINDER de la std de rustc, que sin `+crt-static` se enlaza dinámico contra el libgcc_s de
|
|
# Alpine. Por eso el fix no es `-static-libgcc` (eso es para C/C++): es dejar de pisar la fase del lab.
|
|
# Contraste que lo prueba: cargo-hack también es Rust puro, no tiene fase compile custom, y sale
|
|
# ET_EXEC estático. Misma toolchain, único delta = quién arma el `cargo`.
|
|
#
|
|
# `flags = ["--bin", "tuc"]`: el path default usa `cargo rustc -- <flags>`, que exige UN único target,
|
|
# y tuc expone lib + bin homónimos.
|
|
# de package() de Alpine (traducido $pkgdir→/out):
|
|
install = '''
|
|
_abuild_phase() {
|
|
install -Dm755 target/release/tuc -t "/out"/usr/bin/
|
|
}
|
|
_abuild_phase
|
|
'''
|