sergio/takana

1# rust-toolchain-bin — el compilador de Rust, PRECOMPILADO por upstream y sellado tal cual.
2#
3# ══ POR QUÉ ESTA RECETA EXISTE, Y POR QUÉ ES `foreign` ═════════════════════════════════════════
4# Decisión del usuario (2026-09-14): *«sin compilador de rust, takana no tiene sentido»*. Y tiene
5# razón por una vía que no es de gusto: **todo el instrumental de takana es Rust** —12 crates,
6# 42 555 líneas— y hasta hoy el `rustc` que los construye sale del **LAB**, un rootfs Alpine ajeno.
7# Como el lab entra en el `ArtifactHash`, la distro depende de bytes de otro para poder
8# reconstruirse a sí misma: eso contradice el invariante central, y no se ve porque funciona.
9#
10# El corpus tenía **44 recetas `cargo-*` y CERO recetas de `rustc`/`cargo`** — 44 subcomandos sin el
11# programa, [[subcomando-sin-driver]] a escala de toolchain.
12#
13# **`foreign = true` porque son bytes ajenos, no un build nuestro.** No reproduce desde fuente: lo
14# que se sella es exactamente el tarball que publica rust-lang, verificado por su `sha256` oficial.
15# La marca no cambia el build en nada y sí cambia cómo lo cuenta el grafo (clase `ajeno`, fuera del
16# denominador de «cuántas recetas construimos»). Sin ella, meter un prebuilt inflaría la cifra que
17# todo el mundo lee como corpus — el riesgo que el ADR 0015 puso por escrito.
18#
19# ══ ESTO ES EL PASO 1 DE TRES, Y LOS OTROS DOS NO SON OPCIONALES ═══════════════════════════════
20#   1. **este** — desbloquea HOY que una caja takana compile Rust, y dice la verdad sobre su origen.
21#   2. `rustc` desde fuente con el `llvm18` que YA está sellado en el corpus (379 M). Ahí Rust pasa
22#      a ser nuestro.
23#   3. La cadena `mrustc → 1.90 → 1.91.0 → 1.91.1`, que ya existe documentada en el selfhost
24#      (`docs/10-roadmap.md`, `docs/11-bootstrap.md`) pero vive en el bootstrap, no en el corpus.
25#      Es la que quita la última dependencia de bytes ajenos.
26#
27# ⚠ El target es **musl**, no gnu: es un toolchain que CORRE sobre musl, que es lo que esta distro
28# tiene. Un `x86_64-unknown-linux-gnu` traería el cargador de glibc y sería [[needed-colgante-libstdcxx]]
29# otra vez — instalado, sellado y sin poder ejecutarse.
30name    = "rust-toolchain-bin"
31version = "1.97.0"
32license = "MIT OR Apache-2.0"
33foreign = true
34
35[source]
36tarball = "https://static.rust-lang.org/dist/rust-1.97.0-x86_64-unknown-linux-musl.tar.xz"
37sha256  = "4cebf1c593fcdccf40adb8bc5ef187c3e0dd99f465f9dab48d1a45310ba0de63"
38
39[build]
40compiler = "zig-cc"
41target   = "x86_64-linux-musl"
42link     = "static"
43flags    = []
44
45[build.phases]
46configure = "true"
47compile   = "true"
48# El tarball trae su propio `install.sh` con componentes (`rustc`, `cargo`, `rust-std-*`). Se usa el
49# instalador de upstream en vez de copiar a mano: sabe qué componente va dónde y mantiene el
50# `manifest` que `rustup` y el propio toolchain esperan encontrar.
51# `--disable-ldconfig`: no hay ldconfig acá y su ausencia haría fallar el instalador por un paso que
52# en una distro de binarios estáticos no significa nada.
53install   = "./install.sh --prefix=/out/usr --disable-ldconfig --components=rustc,cargo,rust-std-x86_64-unknown-linux-musl"
54
55# ══ LO QUE COSTÓ HACERLO CORRER, MEDIDO EN LA CAJA ═════════════════════════════════════════════
56# El artefacto sella (799 M) y **no ejecuta** hasta tener dos cosas que la distro publica por
57# separado. Ninguna se ve en el grafo: las dos son `sealed` y estaban en el perfil equivocado.
58#
59# 1. **El cargador musl.** `rustc` es PIE DINÁMICO (`NEEDED librustc_driver-*.so`, `NEEDED libc.so`).
60#    En el worker ni arranca —`cannot execute: required file not found`, que es como se ve la
61#    ausencia del intérprete—; en la caja sí, porque ahí está `musl-shared`.
62# 2. **`libgcc_s.so.1`.** Con el cargador puesto, el siguiente error fue
63#    `Error loading shared library libgcc_s.so.1 … _Unwind_Resume: symbol not found`. Lo publica
64#    `gcc-libs`, que estaba sellado y declarado **sólo en los cuatro perfiles de escritorio**. Una
65#    línea en `base` y listo. (Tercera vez hoy que aparece la misma figura: el paquete existe y no
66#    viaja en la imagen que lo necesita.)
67#
68# Con eso: `rustc 1.97.0` y `cargo 1.97.0` responden en la caja.
69#
70# ══ Y NO HACE FALTA UN `cc` ════════════════════════════════════════════════════════════════════
71# El primer `rustc hola.rs` falla con `linker \`cc\` not found`: la caja no tiene compilador de C.
72# No hace falta traer uno — **el toolchain trae su propio `lld`**
73# (`lib/rustlib/<target>/bin/rust-lld` y su `gcc-ld/`), y con
74#
75#     -C linker-flavor=ld.lld -C linker=<…>/rust-lld -C link-self-contained=yes
76#
77# enlaza y el binario CORRE. Probado en la caja: `fn main(){println!("ok");}` → `ok`. Es una
78# propiedad que vale anotar: una distro sin compilador de C puede compilar Rust igual.
79#
80# ⚠ Pendiente (config del SITIO, no de la receta): que esas flags sean el default, con un
81# `/etc/cargo/config.toml` o el `CARGO_TARGET_*_LINKER` correspondiente, para que `cargo build`
82# funcione sin recordarlas.